I'm trying to change the build process for target AVR so that different sub architectures end up in different subfolders.  At the moment the default behaviour is that e.g. the RTL object files are saved to ./rtl/units/avr-embedded, regardless of the subarch specified.  This means that if one rebuild the RTL for AVR with a different subarch, the previous subarch unit files (system, strings charset etc.) are overwritten.

Since I'm not familiar with makefile syntax or the general build process for FPC I would like a review of my approach described below.

I've modified the fpcmake.ini file to take the subarch (and ABI if specified; according to Florian's svn branch target-subdir) into account. The following two new variables are set according to the SUBARCH and ABI (at the moment for AVR only for testing purposes):

SUBARCH_ABI_SUFFIX=
FILESUFFIX=
ifeq ($(FULL_TARGET),avr-embedded)
ifneq ($(SUBARCH),)
ifneq ($(ABI),)
SUBARCH_ABI_SUFFIX=/$(SUBARCH)/$(ABI)
FILESUFFIX=.$(SUBARCH).$(ABI)
else
SUBARCH_ABI_SUFFIX=/$(SUBARCH)
FILESUFFIX=.$(SUBARCH)
endif
endif
endif

The following variables are passed either via -Fu or -FU to compile instructions and hence where modified:
UNITSDIR:=$(wildcard $(FPCDIR)/units/$(TARGETSUFFIX)$(SUBARCH_ABI_SUFFIX)) COMPILER_UNITTARGETDIR=$(PACKAGEDIR_MAIN)/units/$(TARGETSUFFIX)$(SUBARCH_ABI_SUFFIX)

Update install dirs:
INSTALL_BINDIR:=$(INSTALL_BINDIR)/$(TARGETSUFFIX)$(SUBARCH_ABI_SUFFIX)
INSTALL_UNITDIR:=$(INSTALL_BASEDIR)/units/$(TARGETSUFFIX)$(SUBARCH_ABI_SUFFIX)

Update file name/extension variables:
ZIPSUFFIX=.$(TARGETSUFFIX)$(FILESUFFIX)

This works if I make crossall for AVR and creates the cross compiler, builds the rtl and moves the compiled units into the correct folder /rtl/units/avr-embedded/avrxx. There is a problem compiling the package rtl-extra, since the makefile/fpmake system in that folder overrides the inherited makefile variables.  For now I've disabled target embedded for that package and then the build process for AVR completes without further issues.  

So further questions:
1. I would like to know how to tweak the makefile/fpmake settings for this package to also use the modified subdirs as defined in the default makefile template.
2. How do I test the install and zipinstall targets, I never use them.
3. Is this more or less a feasible route to achieve this behaviour?

Regards,
Christo

Florian has work-in-progress patches for this problem (originally intended for ARM though it should probably work for AVR as well). I think he had published them some time ago on the mailing lists, but if not ask him directly.

Regards,
Sven

On Sun, Jul 22, 2018 at 12:55 PM, Sven Barth via fpc-devel <

Florian made some comments about a patch in progress in a different thread. I've seen a branch in svn that is over 3 years old with changes that seem to do mostly what I want. I'm not familiar with the makefile build process, hence my question. At the moment the modifications I made (to Florian's code) seems to work for my use case (AVR, build from source, no install), but I want to test all use cases including zipinstall and install, but I am not sure what the expected output should be. Also there is some complication with fpmake overriding some makefile settings in rtl-extra, this was not covered by Florians modifications.

Well, I got also stuck on the fpmake problem :(

Florian Klämpfl wrote

Well, I got also stuck on the fpmake problem :(

Yes, it appears to me that fpmkunit lack support for subarch & ABI at the moment, else it would have been easy to modify TPackage.GetUnitsOutputDir in a similar way.

A patch to implement the idea is available here: https://github.com/ccrause/fpc-avr/blob/master/ misc/fpc-subarch-abi-target/target-subarch-abi.patch

General approach: include subarch and (if applicable) ABI in target name.
* In fpcmake.ini 
  * add SUBARCH_ABI_SUFFIX variable
  * append SUBARCH_ABI_SUFFIX variable to FULLTARGET variable to form TARGET_SUFFIX variable
* In fpmkunit.pp:
  * add support for new command line options subarch and abi   * include subarch and abi in MakeTargetString function
* In Makefile.fpc:
  * add --subarch and --abi options to FPC_TARGETOPT variable   * remove -Cp%, -P%, -T% and -Ca% from FPCOPT variable

TODO - Update fpcmkcfg once approach is accepted.

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.

Regards,

Joost.

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!

Op 11-08-18 om 10:22 schreef Christo:

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.

As said, i did not really look into your changes. I had Florian's directory layout in mind. Maybe this is also an idea. Florian, what do you think?

PackageVariants can do more than you need, that's true. You only have to define some additional compiler-parameters, and search-paths, the rest will be done automatically.

Regards,

Joost.