Re: Surprising change in behaviour of createSharedLibBuilder
"Steve Hill \(Wireless\) via Scons-users" <[email protected]>
| Newsgroups | gmane.comp.programming.tools.scons.user |
|---|---|
| Message-ID | <DM8PR18MB4469CAAE2DD55A21C70600DFD1A19@DM8PR18MB4469.namprd18.prod.outlook.com> |
Bill, Some are GCC-based but others are not. For the GCC-based ones, is there a simpler approach to producing a Tool? I am always happy to simplify our code… S. From: Bill Deegan <[email protected]> Sent: 20 September 2021 17:23 To: Steve Hill (Wireless) <[email protected]> Cc: SCons users mailing list <[email protected]> Subject: Re: [Scons-users] Surprising change in behaviour of createSharedLibBuilder Steve, Nope, totally the correct way to implement. out of curiosity are none of these gcc or clang based? -Bill On Mon, Sep 20, 2021 at 9:21 AM Steve Hill (Wireless) <[email protected]<mailto:[email protected]>> wrote: Hi Bill, We have written several Tools for compilers, linkers (and other things) not natively supported by SCons. Where possible, we have defined the appropriate environment variables and called the create*Builder helpers to add the appropriate builders into the environment. Should we have done this in a different way? Cheers, S. From: Bill Deegan Sent: 20 September 2021 15:47 To: SCons users mailing list <[email protected]<mailto:[email protected]>> Subject: Re: [Scons-users] Surprising change in behaviour of createSharedLibBuilder Steve, Any API not in the manpage is not subject to depreciation process. As far as this specific change, it was necessary to introduce an intermediary variable for the suffix to properly generate versioned shared library file names and symlinks. Not sure why you're calling createSharedLibBuilder() directly? Perhaps if you can explain why, we can suggest how you should handle this change. -Bill On Mon, Sep 20, 2021 at 1:55 AM Steve Hill (Wireless) via Scons-users <[email protected]<mailto:[email protected]>> wrote: Hi, I’ve just started the process of upgrading from SCons 3.1.2 to 4.2.0 and some of our Tools have been broken by a change that I find surprising. Where we define a ShLib builder, we define $SHLIBPREFIX and $SHLIBSUFFIX, amongst other things, before calling createSharedLibBuilder(env). Moving to 4.2.0, this resulted in the prefix still being honoured, while the suffix was not. By default, the builder now takes $SHLIBPREFIX and $_SHLIBSUFFIX. Could someone explain the reason for the new asymmetry? Is the preferred solution to add the optional argument (SCons.Tool.createSharedLibBuilder(env, "$SHLIBSUFFIX")) or to change our Tools to define $_SHLIBSUFFIX instead of $SHLIBSUFFIX? Thanks, S. _______________________________________________ Scons-users mailing list [email protected]<mailto:[email protected]> https://pairlist4.pair.net/mailman/listinfo/scons-users<https://urldefense.com/v3/__https:/pairlist4.pair.net/mailman/listinfo/scons-users__;!!Niha4SQ!r8vgDSnnSKcVzyrZLdwAO83qTslyKpk7RPORUGVdwDQ52GFuCD1Hoq1b8kzxEyXj6nsNfiok$> _______________________________________________ Scons-users mailing list [email protected] https://pairlist4.pair.net/mailman/listinfo/scons-users