Build Script Phase just before link?

Hi there,


how do I set up a Build Script Phase so that it gets launched after (or along with) compile files, but before a link?


The goal is to add a couple of libraries to the link list. Before compile phase it is too soon — the list would get overwritten later. After a link it is obviously too late.


I can't simply add the libraries to the Link With Libraries phase, for I don't know them beforehand — the list of those libraries is generated externally and the script determines which ones are actually needed.


So far, I have found only an extremely hackish solution — I can add foo.mysuffix to sources, and add the script as a build rule for *.mysuffix. That seems to work, but is ugly beyond ugly; I would really like to simply add the plain build script phase, if I could do that so that it is run at the right moment.


Thanks for any insight,

OC

Replies

When you create a new Run Script, you can move it between any pre-defined steps. Create the new Run Script, click, hold, and drag it in between the Compile Files step, and the Link Library step.

Have you tried that and it worked for you? In which Xcode?


When I tried that, the link still occurred before the script.


In another project for testing purposes I have removed the link-with phase altogether and it still linked. As always I can be wrong, but it seems to me that Xcode does not really interprets this phase as a real build phase; seems to me it just consults its contents to determine which libraries to add, but links automatically at the end of the compile phase, completely regardless of the placement (or even existence) of the link-with phase :/

You can't modify the build process while it is running. I'm not sure what you are describing here. It sounds very unusual. The problem with doing unusual things is that no one else has ever seen anything like that. When it breaks, as unusual things inevitably do, no one can help you fix it.


It sounds like something you could fix with one or more aggregate targets. Or perhaps, a better solution would simply be multiple targets. It doesn't make sense to build the same target with one set of libraries and then build it later with a different set, determined dynamically.

Well I don't know, as always I might be missing something of importance; but I sort of think this is precisely what link listi is for, isn't it?


Anyway with the build-rule-and-special-source it works so far completely reliably. Just is a bit at the hackish side to my liking 🙂

this is precisely what link listi is for, isn't it?


But not as part of the build. You can setup the build parameters ahead of time. You might even set those up dynamically. But that would be the result from a previous phase of the project. A typical Xcode project is just a simple app with hard-coded framework/library dependencies. You can't shove dynamic behaviour into such a project at the build phase level.


Instead, you could have a more complex workspace of multiple sub-projects. Every possible library would be represented by a separate project. Your final app project would have multiple targets. Each target would be the app with a unique combination of libraries. Then you could have an aggregate target that decides which final target needs to be built.


And that's just one way to do it entirely in Xcode. You could also do it using some other build system such as make. You could write your own shell script. But just can't shove it into the build phase without some hacking, at a cost of reliability and adaptability.

Did you find a solution?
I want to add some extra binary size optimization by creating the LLVM IR files that swiftc generates for each module, combine them and running the Osize optimization for this unique file instead of doing it for several module files, create the object files and finally use the linker. This, in theory can reduce the binary size, but I haven’t found a way to inject my script just before the linker happens

if you didn’t find a good way, it would be good if you can tell what was exactly your hacky workaround, it can help me to testing this