[fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures

Christo christo.crause at gmail.com
Sat Aug 11 10:22:13 CEST 2018


On Mon, 2018-08-06 at 13:44 +0200, Joost van der Sluis wrote:
> Op 06-08-18 om 07:32 schreef Christo:
> > 
> > * In fpmkunit.pp:
> >    * add support for new command line options subarch and abi
> >    * include subarch and abi in MakeTargetString function
> I did not have a look at your patch. But this should not be necessary.
> 
> Fpmkunit supports Package-Variants. In principle you could add:
> 
>    AddPackageVariant('subarch', True);
> 
> to your fpmake.pp, and this package and all packages that depend on it 
> will use sub-directories for each 'subarch'. To make it work in this 
> case might need some work. (Also: it would be ideal to add the subarch 
> to the rtl-package, but this one is not compiled using fpmake..._
> 
> It would be nice if we could use this mechanism to create the 
> directory-structure you want.
> 
> An example is the lcl, with the different widgetsets. Have a look at 
> lazarus/lcl/interfaces/fpmake.pp.

In my mind it was easier to think of subarch/abi options as extending the target concept, so
each valid combination of CPU-OS-SUBARCH-ABI results in a unique target, which ends up in a
separate directory.  This concept seems to fit in well with the current concept of target=CPU-OS 
and requires minimal changes on both the Makefile side and fpmake side.

This is a bit different to how Florian started his modifications, which was CPU-OS/SUBARCH-ABI.
This created some bifurcation in directory & file name conventions, hence my suggested approach
above.

Note that I am not familiar with the details of fpmkunit. I've looked at lcl/interfaces and here
it seems as if each variant has its own list of units required.  In this case most/all of the
required units stay the same, it is just the used compiled unit paths and unit/binary output
path that would differ.  I'm sure I'm missing something about the way PackageVariants are
supposed to work.

Any further comments/suggestions are welcome!



More information about the fpc-devel mailing list