Discussion:
Adapting MakeFile to make subfolders for targets with sub architectures
Add Reply
Christo
2018-07-22 08:31:12 UTC
Reply
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
Reply
Permalink
Raw Message
Post by 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
Reply
Permalink
Raw Message
On Sun, Jul 22, 2018 at 12:55 PM, Sven Barth via fpc-devel <
Post by 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
Reply
Permalink
Raw Message
Post by 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
Reply
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

Loading...