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 
This created some bifurcation in directory & file name conventions, hence my 
suggested approach

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!
fpc-devel maillist  -  fpc-devel@lists.freepascal.org

Reply via email to