Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures
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-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures
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-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures
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-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures
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-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures
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-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures
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-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures
On Sun, Jul 22, 2018 at 12:55 PM, Sven Barth via fpc-devel < fpc-devel@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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures
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-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Adapting MakeFile to make subfolders for targets with sub architectures
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-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
