[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