[Scons-users] SCons popularity

Sun Jun 14 02:35:23 EDT 2015

All,

Maybe we could do something like -Athing for append, -Pthing for prepend,
and -Rthing for replace?  Not sure if the current parser could handle this,
but it would solve many of the current complaints.

Sorry again for misspeaking about command line variable behavior.  I
obviously misunderstood.

V/R,
William

On Sun, Jun 14, 2015 at 2:18 AM, William Blevins <wblevins001 at gmail.com>
wrote:

> Ray,
>
> I might have been mistaken about something which is rather unfortunate.
> Apparently, commandline defines don't get placed directly into the
> DefaultEnvironment.  I would say this could be done in 1-2 lines of code,
> but you will run into the issue of which variable are replaced vs which are
> appended...
>
> Maybe we could come up with a scheme for doing this with all internally
> supported variables...
>
> I'm a bit sad now,
> William
>
> On Sun, Jun 14, 2015 at 1:49 AM, William Blevins <wblevins001 at gmail.com>
> wrote:
>
>> Ray,
>>
>> Variable examples are C/C++.
>>
>> On Sat, Jun 13, 2015 at 11:50 PM, Ray Sheppard <rsheppar at iu.edu> wrote:
>>
>>>  Hello William,
>>>   I only have experience with the SCons-based packages handed to me. So
>>> possibly my issues are with the way those were created and not what is
>>> possible.  In general, they assume that they know what directory structures
>>> to expect and assume they have write privileges where they don't.
>>>
>>
>> I'm not sure how this is an issue with the tool; might be an issue with
>> where the code was located when executed, build requirements failure, etc.
>> I would expect general practice to have file writes down the SConstruct
>> directory tree, but this is not required.
>>
>>
>>> In addition, they usually "see" a compiler that they should not use and
>>> grab it.
>>>
>>
>> SCons has to make some assumption or it wouldn't do anything.  Compiler
>> can be overridden via variable like CCCOM.
>>
>>
>>> The fact that it is just a piece of a more complicated compiler with
>>> multi-staged compiler flags goes right over its head.
>>>
>>
>> SCons doesn't have a head, but I assume you just want to add compiler
>> flags: CCFLAGS?
>>
>>
>>> In general, executables need to be static because execution directories
>>> are thousands of clock cycles away from either home directories or system
>>> libraries.
>>>
>>
>> I'm not sure how this is an issue with the tool; might be an issue with
>> where the code was located when executed, build requirements failure, etc.
>> I would expect general practice to have file writes down the SConstruct
>> directory tree, but this is not required.
>>
>>
>>> I have posed MPI questions here before that went unresolved.
>>>
>>
>> SCons doesn't support clustering across machines natively; not sure why
>> else you might want messaging passing.  There might be a 3-rd party
>> extension, but I haven't heard of one.
>>
>> There is a shared caching mechanism that might be helpful:
>> http://www.scons.org/doc/HTML/scons-user/ch24.html
>>
>>
>>> I am not a big fan of Auto-xxx/M4/Configure.  I was happy setting my
>>> flags and compilers in a Makefile and letting it go.
>>>
>>
>> Unfortunately, how SCons behaves is up to the build script writer in many
>> cases, but any environment variable can be overridden on the SCons command
>> line including common ones like LIBPATH, CPPPATH, CCFLAGS, compilers, or
>> any other variable.  Here is a bigger list of entries that SCons supports:
>> http://www.scons.org/doc/HTML/scons-user/apa.html
>>
>> There are cases where this will not work if the script writer has
>> explicitly env.Replaced the variable in question thus overriding any
>> cmdline inputs, but I'm not sure how that can be helped other than via
>> communicating build requirements.
>>
>> We can promote good practices, but we cannot enforced them.  I find that
>> many developers learn a tool by  learning just enough to do "anything" and
>> brute forcing the rest.  I have on many occasions scolded my own coworkers
>> for not trying to lookup the API before they "reinvented the wheel".
>>
>> However, a simple set of command line flags to override SCons
>>> assumptions, similar to ./configure --yyy,  is not widely publicized.
>>>
>>
>> The User Guide is very publicized.
>>
>> V/R,
>> William
>>
>>
>>>                                Ray
>>>
>>>
>>> On 6/13/2015 11:28 PM, William Blevins wrote:
>>>
>>>
>>>
>>> On Sat, Jun 13, 2015 at 5:14 PM, Ray Sheppard <rsheppar at iu.edu> wrote:
>>>
>>>> Hi All,
>>>>   For what it is worth, without this functionality, use of SCons on
>>>> supercomputers is problematic.
>>>>           Ray
>>>>
>>>> On 6/13/2015 10:44 AM, Vasily wrote:
>>>>
>>>>>
>>>>> Yes, I was talking about those. I believe you can override their
>>>>> default values by passing them as arguments, like
>>>>> $ scons all INSTALL_ROOT=some-path
>>>>>
>>>>> That would need some testing, though - I did not try setting it to a
>>>>> directory *not* under SConstruct's directory.
>>>>>
>>>>> Thanks,
>>>>> Vasily
>>>>>
>>>>>
>>>>>
>>>>
>>>  It's not clear what you are implying.
>>>
>>> SCons supports setting variables on the command line, and SCons supports
>>> installing outside the SConstruct directory tree, and supercomputing has
>>> nothing to do with either of these items.
>>>
>>>  V/R,
>>>  William
>>>
>>>
>>>>  _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-users at scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Scons-users mailing listScons-users at scons.orghttps://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20150614/67fc40d9/attachment.html>