[Scons-users] Windows Subsystem for Linux (WSL) with SCons for cross-compiling

[Bill Deegan]

I"m going to agree with Jason.
I'd advise against having one SConstruct which builds windows and linux
directly.
Have a linux SConstruct and have your windows run that via wsl.  (It can
likely use the same SConscripts though assuming they access the same
filesystem)
You'll have to add appropriate sources and targets to that env.Command().

SCons interrogates the system it's on to decide about initializing various
tools. To get scons to think it's on a linux system when it does such on a
windows system, but only for one Environment() would be likely way more
work than it's worth.

BTW - Mats - I wouldn't consider this really cross building as it's really
building on linux from windows.  And it's not that bad to setup.  Of course
pull request to make it easier to cross compile and/or docs/wiki pages
always welcome.. ;)


-Bill



On Thu, Jun 20, 2019 at 7:50 AM Mats Wichmann <mats at wichmann.us> wrote:

> On 6/20/19 1:56 AM, Christian Butcher wrote:
> > Dear Scons-Users List,
> >
> > I'm currently using SCons to build a series of packages (on a Windows
> > machine) using a tool that I've written based on the example
> > here: ToolsForFools <https://github.com/SCons/scons/wiki/ToolsForFools>
> >
> > I'm now trying to add compilation of a shared library (C++ code) that
> > one of these packages depends on. I'd like to build using the Windows
> > Subsystem for Linux to reduce necessary tools on my build machine (i.e.
> > avoid MSVC + some tool for Linux compilation).
> >
> > I have 3 target cases - Windows 32-bit, Windows 64-bit and Linux 32-bit,
> > all as shared libraries (.dll, .dll, .so). The library depends on an
> > existing 3rd-party library (thirdPartyLib32.dll, thirdPartyLib64.dll,
> > libthirdParty32.so, currently all stored in the same directory within
> > the source repository (git, not SCons)).
> >
> > If I run directly from PowerShell, I can compile the library using
> > command lines like the following:
> >
> > W32
> > wsl i686-w64-mingw32-g++ -o test.dll Relative/Path\
> > With/Space/srcFileA.cpp Relative/Path\ With/Space/srcFileB.cpp  -shared
> > -IRelative/Path\ To/Headers -D_WIN32 -DMYLIB_EXPORTS -fvisibility=hidden
> > -O3 -L Relative/Path\ To/3rdPartyLib -lthirdPartyLib32
> >
> > W64
> > wsl x86_64-w64-mingw32-g++ -o test.dll Relative/Path\
> > With/Space/srcFileA.cpp Relative/Path\ With/Space/srcFileB.cpp  -shared
> > -IRelative/Path\ To/Headers -D_WIN32 -DMYLIB_EXPORTS -fvisibility=hidden
> > -O3 -L Relative/Path\ To/3rdPartyLib -lthirdPartyLib64
> >
> > Linux32
> > wsl g++ -o test.so  Relative/Path\ With/Space/srcFileA.cpp
> > Relative/Path\ With/Space/srcFileB.cpp -shared -IRelative/Path\
> > To/Headers -D_WIN32  -DLINUX_BUILD_MODE -DMYLIB_EXPORTS
> > -fvisibility=hidden -O3 -L Relative/Path\
> > To/3rdPartyLib -lthirdPartyLib32 -fPIC -m32 -Wno-attributes
>
> this all seems odd - you're calling bash to build things, which should
> be fine for the Linux target, but for the Windows cases you'll be
> building in a context where the platform looks like Linux, and scons, I
> would guess, might get some things confused.  In my experience,
> cross-building things with scons is non-trivial (more expert folks will
> probably disagree with me here, it's just an opinion).
>
> >
> > (although the -Wno-attributes is probably a) irrelevant to this
> > discussion, and b) a sign that I need to work on my macro for the Linux
> > compilation...)
> >
> > I suspect that doing this with an Action might be fairly simple, but
> > would perhaps lose the ability to check for source changes unless I also
> > use a Depends call.
> >
> > If I use SharedLibrary, I keep getting an error that SConsEnvironment
> > object has no attribute 'SharedLibrary'. I understand this is due to my
> > overwriting the 'tools' input to the Environment constructor, but using
> > tools = ['default', 'myTool'] doesn't help.
> > Why is this? Which values need to be written (and can these be written
> > after the initialization of the Environment?). I've tried setting things
> > like env['SHCXX'] and env['CXX'] but this produces no visible change (at
> > least to the error - the changes are visible when printing env.__dict__).
>
> as I think you've perhaps surmised, there's a list of builders and a
> list of tools and they're synergistic - if a builder needs a tool, and
> the tool is either omitted from the environment or doesn't initialize
> because something is missing, then the builder that needs it will be
> unavailable. leaving 'default' in the tool list should have kept the
> SharedLibrary builder at least from vanishing.
>
> If you dump the environment, what is in your list of BUILDERS?  You can
> use the dict as you did, but env.Dump() formats a little prettier.
>
> And what are your values for CC, CXX and SHLINK which are going to be
> the most important bits?
>
> > What is the correct/best/most SCons-like way to do this? Should I be
> > setting the 'platform' value when creating the Environment (and would I
> > need to write a new platform object?)? Should I avoid the SharedLibrary
> > builder and use Action + Depends or similar?
>
> Perhaps a bit more debugging.  I wish scons had consistent logging so
> you could tell it to record the decisions it makes as it initializes
> tools, decides whether builders are usable, etc.  Some places have it
> (the msvc tool uses the Python logging module as do a couple of other
> places, but that's not carried out consistently across the codebase).
>
> I don't know it's advisable to give up on SharedLibrary yet, maybe a
> little bit more poking around is warranted.
>
> How are you planning to tell the environment that it should prepend
> 'wsl' to the build lines?  I imagine you would modify the relevant *COM
> variables - once we know if it's finding any at all.
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20190620/c788244a/attachment.html>