[Scons-users] Assembly compiler flags

[Keith Snively]

On Tue, Oct 10, 2023 at 11:54 AM Mats Wichmann <mats at wichmann.us> wrote:

> On 10/10/23 08:49, Keith Snively wrote:
> > I have a project that invokes an assembler as part of the compilation
> > process. Starting with version 4.5.0, there appears to be an issue with
> > the flags that are supplied to the compiler though.  Basically, it is
> > taking the flags supplied to CPPDEFINES and truncating them to the first
> > letter only.
> >
> > In this case, I am compiling boost.  Here is a SConstruct excerpt that
> > sets the CPPDEFINES:
> >
> > local_env = env.Clone()
> >
> > local_env.AppendUnique(CPPDEFINES = ['BOOST_ALL_NO_LIB=1',
> > 'BOOST_CHRONO_DYN_LINK=1', 'BOOST_CONTEXT_DYN_LINK=1',
> >                                       'BOOST_CONTEXT_SOURCE',
> > 'BOOST_DISABLE_ASSERTS', 'BOOST_THREAD_BUILD_DLL=1',
> >                                       'BOOST_THREAD_USE_DLL=1',
> 'NDEBUG'])
> >
> > ...
> > library_build = local_env.SharedLibrary(target=path.join(env['MY_LIBS'],
> > lib_target), source=sources)
> >
> > The expected compile output (On Windows using VS 2019) is:
> >
> > ml64 /nologo /DUSE_CPP /DGL_GAME_WIDGETS /DNO_DEVUTIL_STRACE
> > /DBOOST_ALL_NO_LIB=1 /DBOOST_CHRONO_DYN_LINK=1
> > /DBOOST_CONTEXT_DYN_LINK=1 /DBOOST_CONTEXT_SOURCE
> > /DBOOST_DISABLE_ASSERTS /DBOOST_THREAD_BUILD_DLL=1
> > /DBOOST_THREAD_USE_DLL=1 /DNDEBUG /DBOOST_CONTEXT_EXPORT=EXPORT
> > /DBOOST_THREAD_WIN32 /D__STDC_LIMIT_MACROS /c
> > /Foasm\jump_x86_64_ms_pe_masm.obj asm\jump_x86_64_ms_pe_masm.asm
> >
> > Starting with version 4.5.0, the compile output is:
> >
> > ml64 /nologo /DU /DG /DN /DB /D_ /c /Foasm\jump_x86_64_ms_pe_masm.obj
> > asm\jump_x86_64_ms_pe_masm.asm
> >
> > It looks like it only keeps the first letter of the defines and then
> > removes duplicates (e.g. the /DB ).
>
> the removing duplicates is because you asked it to (AppendUnique rather
> than Append), obviously they shouldn't be getting stripped to a single
> character so they look like dupes!
>
> This is pretty odd... construction variables for the Microsoft assembler
> are set up by the masm tool (SCons/Tool/masm.py) which: (a) doesn't know
> about ml64.exe, unless that magically falls over (actually, it's set to
> invoke the compiler, not the assmbler directly), (b) hasn't changed
> materially since 2008, and (c) doesn't do anything to the conversion of
> CPPDEFINES to command-line output (namely, _CPPDEFFLAGS) - so if this
> fails for assembly, it should fail similarly with compilation of C/C++
> code. Does it?
>
> There *have* been changes to the special-case code of appending to
> CPPDEFINES - since that is something I worked on, I'll look into this,
> but at the moment I can't make this happen with just trivial evaluation:
>
> env = Environment()
> env.AppendUnique(
>      CPPDEFINES=[
>          'BOOST_ALL_NO_LIB=1',
>          'BOOST_CHRONO_DYN_LINK=1',
>          'BOOST_CONTEXT_DYN_LINK=1',
>          'BOOST_CONTEXT_SOURCE',
>          'BOOST_DISABLE_ASSERTS',
>          'BOOST_THREAD_BUILD_DLL=1',
>          'BOOST_THREAD_USE_DLL=1',
>          'NDEBUG',
>      ]
> )
> print(f"{env['CPPDEFINES']=}")
> print(f"_CPPDEFFLAGS={env.subst('$_CPPDEFFLAGS')}")
>
>
> ...\test-append-defines>py -3.12 scripts/scons.py -Q
> env['CPPDEFINES']=['BOOST_ALL_NO_LIB=1', 'BOOST_CHRONO_DYN_LINK=1',
> 'BOOST_CONTEXT_DYN_LINK=1', 'BOOST_CONTEXT_SOURCE',
> 'BOOST_DISABLE_ASSERTS', 'BOOST_THREAD_BUILD_DLL=1',
> 'BOOST_THREAD_USE_DLL=1', 'NDEBUG']
> _CPPDEFFLAGS=/DBOOST_ALL_NO_LIB=1 /DBOOST_CHRONO_DYN_LINK=1
> /DBOOST_CONTEXT_DYN_LINK=1 /DBOOST_CONTEXT_SOURCE
> /DBOOST_DISABLE_ASSERTS /DBOOST_THREAD_BUILD_DLL=1
> /DBOOST_THREAD_USE_DLL=1 /DNDEBUG
> scons: `.' is up to date.
>
>
> A small reproducer would therefore be really helpful...
>
>
Ugh.  When creating an example I came across the following line in the
SConstruct that copies the CPPDEFINES to ASFLAGS:

    for cdef in local_env['CPPDEFINES']:
        local_env.AppendUnique(ASFLAGS = ['/D' + cdef[0] ])

The issue is the entries in CPPDEFINES were a tuple, but are now a string
(starting in 4.5.0).  Updating this to just append cdef resolves the issue.

Thanks for the help and sorry for the false start.

Thanks,
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20231010/efb68b5b/attachment.htm>