Uploaded image for project: 'PLCrashReporter'
  1. PLCrashReporter
  2. PLCR-497

MacOSX targets fail when project path contains a space

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2
    • Fix Version/s: 1.2
    • Component/s: None
    • Labels:
      None
    • Only Affects (Apple):
      Mac OS X

      Description

      With Xcode 4, building the CrashReporter-MacOSX or CrashReporter-MacOSX-Static targets fails because of an apparent issue in Xcode's preparation of the Header Search Paths build variable when compiling mig .defs files.

      With Xcode 5, the problem seems to be alleviated by corrected preparation of build variables for mig.

      To reproduce the problem, just place th CrashReporter sources in a path with a space, e.g.:

      /my/path/to/some folder/CrashReporter.xcodeproj

      Then build with Xcode 4, e.g.:

      DEVELOPER_DIR=/Applications/Xcode4.app/ xcodebuild

      An error occurs because mig receives command line flags e.g. like:

      "-I/my/path/to/some folder/Dependencies/protobuf-2.0.3/include"

      When compiling with Xcode 5, the command line flag is correctly prepared:

      "-I/my/path/to/some\ folder/Dependencies/protobuf-2.0.3/include"

      I'm not sure if there is a reasonable workaround. I can't seem to massage the header search paths variable sufficiently to avoid the faulty quoting. I just thought I would report it for the record in case anybody has a solution that would allow for clients who build on Xcode4 with spaces in the path to continue working as expected.

      1. MigCompileWorkaround.diff
        2 kB
        Daniel Jalkut
      2. MigCompileWorkaroundV2.diff
        1 kB
        Daniel Jalkut

        Activity

        Hide
        Daniel Jalkut added a comment -

        In my "correct" line I accidentally left quotes in that are not there. This is how Xcode 5 actually prepares the argument:

        -I/my/path/to/some\ folder/Dependencies/protobuf-2.0.3/include

        Show
        Daniel Jalkut added a comment - In my "correct" line I accidentally left quotes in that are not there. This is how Xcode 5 actually prepares the argument: -I/my/path/to/some\ folder/Dependencies/protobuf-2.0.3/include
        Hide
        Daniel Jalkut added a comment -

        Patch the CrashReporter xcodeproj so that mig files are processed using a custom script that avoids passing header search paths.

        Show
        Daniel Jalkut added a comment - Patch the CrashReporter xcodeproj so that mig files are processed using a custom script that avoids passing header search paths.
        Hide
        Daniel Jalkut added a comment -

        For what it's worth, the problem can be worked around by providing a custom build rule for Mig files. I essentially defined a custom build rule that invokes mig the same way the system build rule does, but without the HEADER_SEARCH_PATHS being included. Because the Mig file in this case doesn't depend on any imports, it doesn't seem to be an issue, but does alleviate the problem.

        The downside of course is that it permanently locks in time the project's definition of the mig build rule.

        Patch attached, though I will understand if this workaround is considered to clunky to incorporate.

        Show
        Daniel Jalkut added a comment - For what it's worth, the problem can be worked around by providing a custom build rule for Mig files. I essentially defined a custom build rule that invokes mig the same way the system build rule does, but without the HEADER_SEARCH_PATHS being included. Because the Mig file in this case doesn't depend on any imports, it doesn't seem to be an issue, but does alleviate the problem. The downside of course is that it permanently locks in time the project's definition of the mig build rule. Patch attached, though I will understand if this workaround is considered to clunky to incorporate.
        Hide
        Landon Fuller added a comment -

        This doesn't seem unreasonable; MIG hasn't changed in a very long time, and it's unlikely that Xcode will change anything that we'd need to track. It's a bit more fiddly to have to maintain the MIG rule, but I expect we can just set it and forget it.

        Show
        Landon Fuller added a comment - This doesn't seem unreasonable; MIG hasn't changed in a very long time, and it's unlikely that Xcode will change anything that we'd need to track. It's a bit more fiddly to have to maintain the MIG rule, but I expect we can just set it and forget it.
        Hide
        Daniel Jalkut added a comment -

        Cool - if you don't mind taking the patch, it may help some other folks. BTW my original patch was flawed because it asked the mig tool to generate the server sources as well as the client. This led to a link error later at least in the case of the static library.

        Amended patch attached.

        Show
        Daniel Jalkut added a comment - Cool - if you don't mind taking the patch, it may help some other folks. BTW my original patch was flawed because it asked the mig tool to generate the server sources as well as the client. This led to a link error later at least in the case of the static library. Amended patch attached.
        Hide
        Landon Fuller added a comment -

        Fixed in master with revision 15a1010b690cdc094a13ee36c81bf67c8f6df75d.

        Show
        Landon Fuller added a comment - Fixed in master with revision 15a1010b690cdc094a13ee36c81bf67c8f6df75d.

          People

          • Assignee:
            Landon Fuller
            Reporter:
            Daniel Jalkut
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: