From: marcov@stack.nl
On 2005-04-21, Vinzent 'Gadget' Hoefler
wrote:
>>> Another best way might be to define the symbols on the commandline.
>>
>> Dangerous, if you forget it once for a part of the program, you end up
>> with a program that is partially compiled with the define on, and
>> partially off.
>>
>> Even if you typically do a "build", it will go wrong once in a while,
>
> Yes. I already noticed some odd behaviour. FPC seems to have problems if
> the source files are located in several directories. Is that correct?
Not that I know. Watch out thought that includefiles have a separate set
of paths (-Fi) than the units (-Fu). So if a dir is searched for units,
it is not automatically searched for includefiles.
Also the .inc auto-dependancy has a disadvantage if you have multiple
includefiles with the same name. A notorious one is that if you try to
compile a program using an includefile with the same name as a file in the
RTL. (e.g. i386.inc), the compiler then wants to recompile the RTL.
For this, the -Ur parameter exists, it turns off the dependancy on .incs and
sourcefiles, and it is used to compile release RTLs, to avoid this.
>> which is why I switched to includefiles.
>
> Ok, I wasn't aware that include files are actually considered as
> dependencies in the normal compilation process (I simply don't use
> include files), but a small test revealed that FPC seems smart enough
> to do so. :)
Yes. However I didn't know that BP didn't. Too long ago :_)
> So, yes, you're right, include files seem to be the better option at
> least as far as FPC is concerned. But it's not that easy then to just
> say the usual -dDEBUG, -dRELEASE and such, or even put those as
> different targets into a small makefile.
For one or two yes. However includefile allow for a lot more complexity,
see e.g. the TV or Jedi includefiles.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
