Discussion:
Adapting MakeFile to make subfolders for targets with sub architectures
(too old to reply)
Christo
2018-07-22 08:31:12 UTC
Permalink
Raw Message
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
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org
Sven Barth via fpc-devel
2018-07-22 10:55:31 UTC
Permalink
Raw Message
Am 22.07.2018 um 10:31 schrieb Christo:
> 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.
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
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-b
Christo Crause
2018-07-23 10:42:58 UTC
Permalink
Raw Message
On Sun, Jul 22, 2018 at 12:55 PM, Sven Barth via fpc-devel <
fpc-***@lists.freepascal.org> wrote:

> Am 22.07.2018 um 10:31 schrieb Christo:
>
>> 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.
>>
> 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.
>

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.
Florian Klämpfl
2018-07-26 20:19:05 UTC
Permalink
Raw Message
Am 22.07.2018 um 12:55 schrieb Sven Barth via fpc-devel:
> Am 22.07.2018 um 10:31 schrieb Christo:
>> 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.
> 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.

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

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/li
Christo
2018-07-28 20:48:40 UTC
Permalink
Raw Message
On Thu, 2018-07-26 at 22:19 +0200, 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.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepas
Christo
2018-08-06 05:32:30 UTC
Permalink
Raw Message
On Sat, 2018-07-28 at 22:48 +0200, Christo wrote:
> On Thu, 2018-07-26 at 22:19 +0200, 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.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailma
Joost van der Sluis
2018-08-06 11:44:11 UTC
Permalink
Raw Message
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.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://l
Christo
2018-08-11 08:22:13 UTC
Permalink
Raw Message
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!
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinf
Joost van der Sluis
2018-08-13 19:50:07 UTC
Permalink
Raw Message
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?

> 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.

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.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepasca
Loading...