Hey all,
I've been maintaining the Free Pascal Compiler [0] in Fedora for some time now.
A couple of times I played around with the idea of building and packaging FPC
cross-compilers. Lately I gave it another go and arrived and some quite
workable results. If you're interested, you can check them out in COPR. [1]
During the process of packaging the cross-compilers, there were a couple of
issues I came across and wanted to ask for some opinion/guidance.
1. Separate package or not
The most basic issue would be whether the cross-compilers should be built from
a separate SRPM, or be a part of the main package. For both possibilities,
I see some pros and cons.
Cross-compilers in one package:
+ Everything's in one place
+ The cross-compilers are built from the same source
- Main .spec file becomes way more complicated
- Package for native compiler can get blocked by cross-compilers not building
Separate package for cross-compilers:
+ The spec for the native compiler can remain relatively simple
+ Worst case scenario, we can ship an updated version of the native compiler
and fix cross-compiler errors later
- A lot of duplication between native and cross .spec file
- Need to track sources/patches from main package in the cross package,
comes with a risk of things de-syncing
Personally I'd favour the "separate package" approach.
2. Naming - base name
Yes, the eternal problem. So far, I went with naming the cross-compiler package
"fpcross", which reflects what upstream does - e.g. if the native compiler
for aarch64 is "ppca64", the cross-compiler is "ppcrossa64".
I wonder if using "fpc-cross" would be more readable. Yet another solution
would be to hide the native/cross distinction and use "%package -n" to build
cross-compilers with just the "fpc-" prefix.
3. Naming - per arch
So far, for simplicity, I went with naming the cross-compilers
"fpcross-${ARCH}", e.g. "fpcross-aarch64", with packages for MS Windows
being named "fpcross-win32" and "fpcross-win64". Looking at some other
packages (like binutils), I wonder if it would be better to use the arch+os
format, like "fpcross-i386-linux" and "fpcross-i386-win32".
4. Configuration
FPC uses a configuration file, located at /etc/fpc.cfg (it can be overridden
by a user creating a file at ~/.fpc.cfg, but that's beside the point).
Inside said config file, there's this problematic bit:
#IFDEF CPU64
-Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget
-Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget/*
-Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget/rtl
#ELSE
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl
#ENDIF
This tells the compiler that, when compiling for 64-bit targets, it should
look for unit files in "/usr/lib64/fpc/...", and when compiling for 32-bit
targets, to look in "/usr/lib/fpc/...". The problem here is that this is
based on the *target* architecture, not the *host* architecture, so
cross-compiling from x86_64 for i386 will have the compiler look in /usr/lib/
instead of /usr/lib64/. Which brings the following dilemma:
a) Install stuff required to cross-compile for 32-bit targets in /usr/lib/,
instead of the more appropriate /usr/lib64/.
b) Instead of using the default config file, ship a custom one that makes
the compiler always look in /usr/lib64/ on 64-bit arches
and /usr/lib/ on 32-bit arches.
I think that from a packaging perspective, b) would be cleaner,
though it adds yet one more thing that needs maintaining.
Let me know what you think.
Cheers,
A.FI.
[0] https://src.fedoraproject.org/rpms/fpc
[1] https://copr.fedorainfracloud.org/coprs/suve/fpcross/
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
