[fpc-pascal] PROJECT_DERIVED_FILE_DIR

[Jonas Maebe]

On 02 Nov 2006, at 19:03, Ken G. Brown wrote:

> With fpc, in trying to compile an example brought in from CW, and  
> using XCode 2.4.1 on a Dual 2.0 G5 10.4.8, I have started with a  
> Carbon template. In the target rules for processing pascal source  
> files, I see a custom script indicated to use output files $ 
> (PROJECT_DERIVED_FILE_DIR)/$(INPUT_FILE_BASE).s
>
> How do you look at the value that PROJECT_DERIVED_FILE_DIR is set to?

By looking at the build transcript. To see it, go to the "Build  
Results" (cmd-shift-B), and then click on the small icon looking like  
a couple of lines of text (next to a yellow warning triangle -- yes,  
the user interface of that pane is bad).

> And where would you change the setting? I cannot find it in any  
> documentation.

You can't change it, it's automatically set by Xcode. You can find  
out about it (and tons of others) by having a look at the build  
transcript mentioned above.

> Is the custom script necessary?

Yes.

> I am getting a compile error saying:
> powerpc-apple-darwin8-gcc-4.0.1: no input files while looking  
> for .s file in the Build/projectname.build/DerivedSources directory.
>
> Is a .s always created from Pascal Sources during compiles?

Yes.

> I see a program.s file in Build/projectname.build/DerivedSources/ 
> PPC/ directory but am not sure why it cannot be found or what to do  
> about it.

The compilation script should copy it to Build/projectname.build/ 
DerivedSources after compilation is finished, merging ppc and intel  
versions of the assembler code if necessary (because in the past  
Xcode did not allow specifying different output files for different  
architectures). This should be done by the make_conditional()  
function in the compilation script.

You may also want to try Erling Johanssen's alternate Xcode project  
files, available from
   http://www.fabfilter.com/frederik/fpc-app-templates-20060921-ejo.zip

They are written for Xcode 2.3 or later and therefore need far less  
workarounds for Xcode bugs and limitations (and hence are less prone  
to hard to find bugs). They also solve a few issues with the project  
files we distribute (the main one is that it puts the compilation  
script in a different target to avoid a race condition).


Jonas