Re: How to set executable/product name by compiler switch?
Re: How to set executable/product name by compiler switch?
- Subject: Re: How to set executable/product name by compiler switch?
- From: Jonas Maebe <email@hidden>
- Date: Sat, 9 Jan 2010 22:49:26 +0100
On 09 Jan 2010, at 21:44, Alexander Bokovikov wrote:
> 2. Second problem probably belongs to FPC specifics. I can't make Pascal code to recognize similar precompiled variable, which I add to FPC_XXXX_OPTIONS in the target properties. I don't know how to make FPC to "globalize" this precompiled variable for all FPC units.
>
> I believe these problems are related more to FPC than to XCode.
Well, they are specific to how the FPC Xcode templates are constructed, which in turn is influenced by the way Xcode deals with targets and "run script" phases. I've posted the answer below on the mac-pascal list where Alexander also asked about this, but though it might also be useful to other people working on trying to integrate third party compilers into Xcode (and possibly to Xcode engineers so they might be able give tips on how to make this process less painful).
There are several reasons why what you are doing does not work:
* the FPC Xcode project templates are constructed as follows:
a) an "fpc" target, with two run script phases. One generates a static library containing all FPC run time library files that are installed on the system (which is linked by the main target). The other compiles your main Pascal source file (defined by the FPC_MAIN_FILE project setting), and all the units it depends on, into assembler code.
b) the "<projectname>" target. This one depends on the aforementioned "fpc" target (so it will cause that target to run to completion before starting), and it has build rules for Pascal source files that simply assemble the assembler code generated by said "fpc" target into object code.
So:
* the Pascal code is compiled by the "fpc" target, rather than by other project targets. Other targets merely generate object files out of the assembler code that was generated by the compiler in the "fpc" target. This means that you would have to add the defines either to the project (rather than target) settings, or to the "fpc" target settings. However, since you want to use a different define for different targets, that won't help you.
* The generated assembler files are project-global rather than target-specific. The reason is that since they are generated inside a separate target, there is no way to find out on behalf of which other target they are being generated.
* The reason for compiling the source code in a separate target is twofold:
a) they are compiled inside a "run script" phase rather than via a rule for Pascal source files, because it is not possible for a Pascal compiler to only compile 1 source file. It always automatically compiles all units that this source file depend on. Therefore letting Xcode explicitly compile all Pascal source files that you have added to a target would result in a lot of duplicate and unnecessary compilations.
b) Xcode does not allow specifying the order in which a "run script" phase is executed inside a target relative to the other phases. So if the "run script" phase is part of the application target, then it can be (and often is) run in parallel with the phase that assembles the generated assembler code into object files, resulting either in aborts (because an assembler file has not yet been generated) or in assembling stale assembler files (from a previous compilation)
* Because all of the compiled unit files are stored in a single directory by the "fpc" target (regardless of which target triggered the compilation), simply using a different conditional define (even if you found a way to communicate it to the "fpc" target from the original target) would not be enough, since FPC will not recompile any units simply because you specify a different -d option on the command line. It will only recompile units for which the source code has changed (and the source file specified on the command line -- it's sort of like a built-in "make" system).
The only solution that I see is to
a) duplicate the Xcode "fpc" target
b) change its "Compile Pascal Source" script phase, by changing the following line:
out_dir=$app_target_temp_dir/`basename "$DERIVED_SOURCES_DIR"`-$variant/$arch
into this:
out_dir=$app_target_temp_dir/`basename "$DERIVED_SOURCES_DIR"`2-$variant/$arch
(note the extra 2)
Then
1) override the FPC_COMMON_OPTIONS setting with the appropriate -d parameter for the original and the copied FPC target
2) make one Objective-C app target dependent on the original "fpc" target, and another one of the copy
3) double-click on the on the target that you made dependent on the copy, go to the "Rules" tab, and
a) change the following line in the "custom script" for Pascal sources
destdir="${DERIVED_SOURCES_DIR}-${CURRENT_VARIANT}/${CURRENT_ARCH}"
into
destdir="${DERIVED_SOURCES_DIR}2-${CURRENT_VARIANT}/${CURRENT_ARCH}"
(the extra "2" from above)
b) scroll the window until you are below the text input field for the custom script, and in the "with output files:" text box change
$(DERIVED_SOURCES_DIR)-$(CURRENT_VARIANT)/$(CURRENT_ARCH)/$(INPUT_FILE_BASE).s
into
$(DERIVED_SOURCES_DIR)2-$(CURRENT_VARIANT)/$(CURRENT_ARCH)/$(INPUT_FILE_BASE).s
(once more an extra 2)
This should make the copy of the "fpc" target to compile everything into another directory compared to the original one, hence giving you different sets of units compiled with a different conditional define. And it should make your second target use this second set of code.
If you can think of a generic way to support this sort of stuff in an Xcode project, feel free to propose it. I can't think of any.
Jonas _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden