[Scons-users] Cross-OS Cross-Building

[Jason Kenny]

>>Adding another dependency to GPSD is a non-starter, especially if it's
purely for cross-building.  Having to accomodate a >>range of SCons versions
is trouble enough.

I am sorry to hear, That is a choice you can make. I however have used Parts
to build many large GB project when I was at Intel, such as VTune, and
Inspector. A number of team are still using it today, ( as I have pull
request to resolve for them). I have done a bit of work to make sure I work
with a large range of SCons versions at the same time, to reduce versioning
issue ( I still support SCons 2.1).

>> Well the SCons documentation *claims* it handles cross-building well,
it's just that the claim is overstated. :-)
So does autotools and their many more than 2 dependencies that you have to
install to get it to work.. 
I view SCons claim more as they "make it easy" as a "usable possibility"
while other system don't do it at all, or make it much much harder. Parts
Just tries to make it easier by doing common stuff in a standard way so the
user does not have to duplicate all that work. I would also point out must
other system that do this are not able to easily extend to using new
platforms. I was easily able at Intel to support the not then release K1om
platform (Ie the Phi cards) with SCons and Parts. I can only tell you people
that used this system found it much easier to use than dealing with
non-portable custom makefiles that they had to hand craft. Either way I
respect your view.. cross building is hard.. is should not be

>>The particular issue that prompted the investigation is that when
cross-bulding for Linux on OSX, it wants to use a .dylib >>extension rather
than .so on shared libraries.  The extension is being supplied by SCons, not
the toolchain.  It's probably not >>the only such issue.

Honestly I have not set up a toolchain to cross build for Linux on Mac in
Parts. I will also state Parts toolchain support for Mac is not as good as
it should be ( when compared to Windows, Linux, BSD, SunOs...). I know
personally I would like to setup Parts ( and by proxy SCons) to make dylibs
on Linux builds myself. You have to modify the toolchain for Linux to do
this. It can be done. Parts for example make "PDB" files on linux to
separate debug information from the .SO files. It is another set of command
that have to added to the link stage that people on linux general ignore
doing. This however is a different subject..

>>It already has the means to set up certain construction variables in a
manner appropriate to the platform.  The problem is just >>that it doesn't
make that mechanism available for a specifiable platform, for no terribly
good reason.  Duplicating that logic >>separately would be rather silly....

I not sure what you are referring to here. Normally when you cross build you
setup an shell environment for the host system. You call toolchains, as
compiler to that understand how to output data for the target case in the
environment to run. You add some flags based on that target platform you
need to compile and you are done. What Scons does is allow on to create an
environment with the correct setup to call a given tools correctly. Also
remember SCons is designed to be a make replacement. A very smart person
named Greg was going to write some AutoSCons tool to generate a Sconstruct
for build for only a given platform. He had pointed out issue that are not
ideal from coping autoconf thinking in SCons. However everything in SCons is
setting up items to run a tool correctly on the host. Which is 100% what you
want. Adding other items to build for a different OS or architecture
requires setting some other value in the environment. Given any system that
handles cross build you always have a way to say detail about the host
system independent from the target you are building from. SCons as I said
before defines variables at a Host level, as the "PLATFORM" ( which are
based on values from python os module)

I am curious on what variables you view are the issue? 

Jason