After years of using the legacy build system, I finally gave in and decided to convert my project so that it would build using the modern build system. I gave in because rather than being warned that the legacy build system was deprecated, Xcode 13 now treats it like an error.
My application is available for Windows and Linux too and uses common code written in C/C++ with the GUI written in objective-c (no Swift at all). There's also a console version and shared library version for Python support. There are multiple versions of my application (think lite, consumer, and pro) which I have as separate targets. The console and shared library versions are also separate targets. My application requires a bunch of support files that are contained outside of the main application in a separate directory so I have a custom build location Xcode project setting that places the application into that directory.
-
The modern build system is very slow. I can do a fresh build of the third party libraries, frameworks, and multiple Universal versions of my app using the legacy build system in 8 minutes. The modern build system takes 16 minutes.
-
After I do a fresh build, if I make no changes and build again, all my code (but not the third party libraries and frameworks for some reason) gets recompiled. After the second time though, selecting build again only recompiles changed files. This has been true for years though and is not unique to the modern build system. Although I used precompiled headers, it's not a PCH problem because I turned it off and still observed the same problem.
-
Because I have separate versions of my application in addition to console and share library versions, I put the console and shared library in
MyApp.app/Contents/MacOS/directory. With the legacy build system, I could use set that as the build location for the console and shared library versions but the modern build system now complains about multiple commands producing theMacOSdirectory. So now I have to use an aggregate target (that has the different targets as dependencies) that copy the executable and library to the correct location. And now I have the original console executable and shared library lying around. -
Clean Build Folder no longer works due to the custom build location. I get error messages that the custom build directory can't be deleted. I now use
make cleanfrom a terminal with the-UseModernBuildSystem=NOoption forxcodebuildin the makefile. -
I used to be able to use a single Info.plist file that's macro'd up that's shared by my multiple targets. I have a build phase script that reads the version and build number from a file and injects it into the Info.plist and reverts the file after a target has been successfully built (reverted for source control reasons). But Xcode wants to do parallelized builds so I can no longer modify/revert the single Info.plist file. Each target now must have their own Info.plist file even though they're all identical. Not a problem, I'll copy the source Info.plist file to the target Info.plist file as a build phase and inject the version number into that. Nope, the modern build system doesn't like having files not existing when it's preparing to build even though the files will eventually exist when it gets to that build step.
The worse thing though is how slow the modern build system is.