Re: [Scons-dev] [Scons-users] SCons 4.0.0 Released

[Gary Oberbrunner]

Congratulations! SCons 4.0!!!

On Sat, Jul 4, 2020 at 6:57 PM Bill Deegan 
wrote:

>   A new SCons release, 4.0.0, is now available
>   on the SCons download page:
>
>   https://scons.org/pages/download.html
>
>   Here is a summary of the changes since 3.1.2:
>
>   NEW FUNCTIONALITY
>
> - Added support for scanning multiple entries in an action string if
>   IMPLICIT_COMMAND_DEPENDENCIES is set to 2 or 'all'. This enables
> more thorough
>   action scanning where every item in each command line is scanned to
> determine
>   if it is a non-source and non-target path and added to the list of
> implicit dependencies
>   for the target.
> - Added new module SCons.Scanner.Python to allow scanning .py files.
> - Added support for explicitly passing a name when creating Value()
> nodes. This may be useful
>   when the value can't be converted to a string or if having a name is
> otherwise desirable.
> - Added a new flag called "linedraw" for the command line argument
>  "--tree"
>   that instructs scons to use single line drawing characters to draw
> the dependency tree.
> - Add CompilationDatabase() builder in compilation_db tool.
> Contributed by MongoDB.
>   Setting COMPILATIONDB_USE_ABSPATH to True|False controls whether the
> files are absolute or relative
>   paths.  Address Issue #3693 and #3694 found during development.
> - Extended `Environment.Dump()` to select a format to serialize
> construction variables (pretty, json).
> - New conditional C Scanner (`SCons.Scanner.C.CConditionalScanner()`)
>   which interprets C/C Preprocessor conditional syntax (#ifdef, #if,
> #else,
>   #elif, #define, etc.)
> - Experimental New Feature: Enable caching MSVC configuration
>   If SCONS_CACHE_MSVC_CONFIG shell environment variable is set,
>   SCons will cache the results of past calls to vcvarsall.bat to
>   a file; integrates with existing memoizing of such vars.
> - Preliminary Python 3.9 support.
>
>   DEPRECATED FUNCTIONALITY
>
> - Drop support for Python 2.7. SCons will be Python 3.5+ going forward.
> - Remove deprecated SourceCode()
>
>   CHANGED/ENHANCED EXISTING FUNCTIONALITY
>
> - Added check for SONAME in environment to setup symlinks correctly
> (Github Issue #3246)
> - Resolve Issue #3248 - Removing '-Wl,-Bsymbolic' from
> SHLIBVERSIONFLAGS
>   NOTE: If your build depends on the above you must now add to your
> SHLIBVERSIONFLAGS
> - Microsoft Visual Studio - switch to using uuid module to generate
> GUIDs rather than hand rolled
>   method using md5 directly.
>   NOTE: This change affects the following builders' output. If your
> build depends on the output of these builders
>   you will likely see a rebuild.
>   * Package() (with PACKAGETYPE='msi')
>   * MSVSSolution()
>   * MSVSProject()
> - Improve Visual Studio solution/project generation code to add support
>   for a per-variant cppflags. Intellisense can be affected by cppflags,
>   this is especially important when it comes to /std:c++* which
> specifies
>   what C++ standard version to target. SCons will append
> /Zc:__cplusplus
>   to the project's cppflags when a /std:c++* flag is found as this is
>   required for intellisense to use the C++ standard version from
> cppflags.
> - Allow user specified location for vswhere.exe specified by VSWHERE.
>   NOTE: This must be set at the time the 'msvc' 'msvs' and/or 'mslink'
> tool(s) are initialized to have any effect.
> - Fixed Github Issue 3628 - Hardcoding pickle protocol to 4 (supports
> python 3.4+)
>   and skipping Python 3.8's new pickle protocol 5 whose main advantage
> is for out-of-band data buffers.
>   NOTE: If you used Python 3.8 with SCons 3.0.0 or above, you may get
> a a pickle protocol error. Remove your
>   .sconsign.dblite. You will end up with a full rebuild.
> - MSVC updates: When there are multiple product installations (e.g,
> Community and
>   Build Tools) of MSVC 2017 or MSVC 2019, an Enterprise, Professional,
>   or Community installation will be selected before a Build Tools
> installation when
>   "14.1" or "14.2" is requested, respectively. (GH Issue #3699).
> - MSVC updates: When there are multiple product installations of MSVC
> 2017 (e.g.,
>   Community and Express), 2017 Express is no longer returned when
> "14.1" is
>   requested.  Only 2017 Express will be returned when "14.1Exp" is
> requested.
>   (GH Issue #3699).
> - MSVC updates: pass on VSCMD_DEBUG and VSCMD_SKIP_SENDTELEMETRY to
> msvc
>   tool setup if set in environment. Add Powershell to default env
>   (used to call telemetry script).
> - Renamed as.py to asm.py and left redirecting tool.  'as' is a
> reserved word and so
>   changing the name was required as we wanted to import symbols for
> use in compilation_db
>   tool.
> - Add no_progress (-Q) option as a

Re: [Scons-dev] bug prune

[Gary Oberbrunner]

I think this would be great. I'll help review the bugs-to-be-closed.

-- Gary

On Tue, Aug 27, 2019 at 8:50 AM Mats Wichmann  wrote:

>
> Just to pull some thoughts together:
>
> there are currently 679 open scons issues on github.
>
> That number drops to 92 if you select only ones which have had a
> modification since the big migration from tigris. Try this query:
>
> is:issue is:open updated:>=2018-02-10
>
> or as a link:
>
>
> https://github.com/SCons/scons/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+updated%3A%3E%3D2018-02-10+
>
> I'm a relative newcomer around here, but I don't see the value of
> showing a ton of historical bugs that aren't being worked on; the newly
> filed ones don't even get a lot of attention - there just isn't a big
> scons team at this point and numerically most current contributors have
> a specific motivation ("itch to scratch" as it were) rather than the
> ability to just generally work on bugs.  To provide more visible focus
> there's already been some discussion of a bug prune.
>
> My suggestion is this:
>
> (a) close all open tigris bugs with a message that includes these items:
>
> * bug is now tracked on github [link]
> * bugs which have not had activity in 18 months are going to be closed
> (it doesn't have to be 18, but that was the cutover time)
> * we understand readers of this issue might not see messages from
> github, so if you want to keep this issue alive, make a comment - any
> comment - on the corresponding github issue.
>
> (b) fire up a bot to mark inactive github issues with a tag, and
> configure suitably.  Looks like there's an app in the github marketplace
> that is free so setup is just a YAML file. Example setup here:
>
>
> https://github.com/timgrossmann/InstaPy/commit/afd968dfa1ce1141456a207484d35f2766d5916b
>
> the app:
>
> https://github.com/marketplace/stale
>
> (c) someone scan through the first-time closure proposal list and
> manually update any which seem deserving of continued life.
>
>
> Closed-as-stale issues don't vanish, they are still there to be browsed
> as needed...
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] [Scons-users] Please try SCons 3.0.4.1 test package

[Gary Oberbrunner]

Works for me with VC 2017 community:

% scons --version
SCons by Steven Knight et al.:
script: v3.0.4.3a41ed6b288cee8d085373ad7fa02894e1903864, 2019-01-20
22:51:36, by bdeegan on kufra
engine: v3.0.4.3a41ed6b288cee8d085373ad7fa02894e1903864, 2019-01-20
22:51:36, by bdeegan on kufra
engine path:
['c:\\tools\\msys64\\msys64\\tmp\\scons-test\\venv\\lib\\site-packages\\scons\\SCons']
% SCONS_MSCOMMON_DEBUG=- scons
scons: Reading SConscript files ...
trying to find VC 14.1
find_vc_pdir_vswhere(): VC found: '14.1'
found VC 14.1
vc.py:get_host_target()
vc.py:get_host_target() req_target_platform:None
_check_cl_exists_in_vc_dir(): host platform amd64, target platform amd64
_check_cl_exists_in_vc_dir(): checking for cl.exe at C:\Program Files
(x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64\cl.exe
_check_cl_exists_in_vc_dir(): found cl.exe!
...
installed_vcs:['14.1']
msvc_setup_env: using default installed MSVC version '14.1'

It didn't find any SDK but I don't think I have one installed so that's
fine.

-- Gary




On Tue, Jan 22, 2019 at 1:44 PM Mats Wichmann  wrote:

> On 1/21/19 10:31 PM, Bill Deegan wrote:
> > Planning in releasing tomorrow.
> > This should fix the issue with 3.0.3 not finding VS/VC 2017
>
>
> This isn't really directly related. There are multiple README files,
> three of them seem fairly key, and they don't entirely agree on some
> basic things - locations for further interaction.
>
> README.rst
> README-local
> src/README.txt
>
> I can prepare a simple patch to align them a bit more, but a couple of
> questions:
>
> * some refer to posting to scons-users and some to scons-dev before
> filing a bug.  Is there an actual delinination between the two that
> should be mentioned, or is it just send to scons-users?
>
> * is the announce list (at tigris) still alive?  it's referred to in
> these three, and the website, but hasn't apparently had a posting since
> 2011 according to its own page.
>
> This is not crucial to any release, and certainly not this one, in my
> opinion, just asking before I forget.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Gary Oberbrunner]

Russel says:

Python 2 is the millstone for SCons 3.

I've been using 3.6 for all recent projects and loving it (async,
f-strings, etc.), but what weight are we really carrying by supporting 2.x?
Seems to me like most 3.6 features can be detected at runtime while still
keeping back compat without too much extra work. But I may be missing
something.

-- Gary

On Sat, Jul 21, 2018 at 7:37 AM Russel Winder  wrote:

> On Fri, 2018-07-20 at 23:20 -0400, Bill Deegan wrote:
> > Pretty certain Gary's with me in saying,
> > SCons will support Python 2.7 and 3.5+ in (at least) the 3.x
> > releases.
> > Most likely through (at least) the end of 2018.
>
> You can add me to agreeing with that.
>
> > I know many who actively participate in SCons community live on the
> > leading
> > edge of OS and Python releases but many users do not.
> > Also, there are still some rough edges to our Python 3 support. Until
> > it's
> > rock solid (and no one has found an issue for a while), dropping py
> > 2.7
> > would be unwise.
>
> I see your finger pointing at me. :-)
>
> We have had not dissimilar maintenance debates in the Apache Groovy
> community, especially now JDK is updated every 6 months instead of
> every 6 years. Clearly there is a need to support people using ancient
> three year old systems. Debian Stable and Ubuntu LTS really set the
> timescales here, and the Python versions. Except that Travis-CI appears
> to think using the most ancient Ubuntu LTS they can is a good thing.
>
> But then come the issues at the heart of the matter: If people are
> using three or five year old platforms, will they be using the very
> latest version of SCons? If they want the very latest SCons why can't
> they install the very latest Python? If they are happy with the three
> year old Python will they actually be happy with the three year old
> SCons? If a distribution provides Python and SCons why is there any
> interest in them updating anything?
>
> Groovy used to have a "we must be totally backward compatible"
> obsession that was over the top, especially for me. Over the last year
> the policy has changed towards something much better, and which has
> allowed Groovy to progress much better in a highly dynamic world.
>
> OK so Java has the big difference that you distribute compiled
> artefacts and there are only link time issues, whereas Python is
> distributed as source so everything is compile time issues. But the
> Groovy team have now begun to accept that "backward compatibility" can
> be taken too far. For each major version of Groovy a lower limit is now
> set and if people are not prepared to update their Java, then they have
> to use the last version of Groovy that works with that version of Java.
>
> Python 2 is the millstone for SCons 3. The question is whether there
> will be a 2.7.16 or whether 2.7.15 is really the last version. Also
> will an organisation break ranks with PSF policy and pick up Python 2.7
> and keep it going? Would that matter for SCons?
>
> I can fully understand sticking with 3.5 at this time, but SCons
> versions must be allowed to change the minimum Python version. Should
> SCons 3.1 require Python 3.6 and drop support for Python 2.7? If yes
> then people not on Python 3.6 simply stay with SCons 3.0.X.
>
> For me this is all about consistency: you can't demand cutting edge
> SCons unless you are prepared to use cutting edge Python.
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Gary Oberbrunner]

Pretty certain Gary's with me in saying,
SCons will support Python 2.7 and 3.5+ in (at least) the 3.x releases.
Most likely through (at least) the end of 2018.


Yes, absolutely. SCons is used by lots of people on older legacy systems.
IMHO it is and needs to be a solid, reliable build tool, not (just) a
leading-edge dev tool.

-- Gary


On Fri, Jul 20, 2018 at 11:27 PM Bill Deegan 
wrote:

> Pretty certain Gary's with me in saying,
> SCons will support Python 2.7 and 3.5+ in (at least) the 3.x releases.
> Most likely through (at least) the end of 2018.
>
> I know many who actively participate in SCons community live on the
> leading edge of OS and Python releases but many users do not.
> Also, there are still some rough edges to our Python 3 support. Until it's
> rock solid (and no one has found an issue for a while), dropping py 2.7
> would be unwise.
>
>
> -Bill
> SCons Project Co-Manager.
>
> On Fri, Jul 20, 2018 at 4:11 PM, Jonathon Reinhart <
> jonathon.reinh...@gmail.com> wrote:
>
>> > True but who uses Debian Stable for anything relating to software
>> > development, it is a server distribution.
>>
>> I'm not sure where you got the idea that Debian is a "server
>> distribution". Lots of people use Debian as a desktop OS, and my team
>> uses Debian for software development.
>>
>> I think SCons would be making a serious mistake if it dropped support
>> for Python 3.5. Just because the distro is using an older version of
>> SCons, doesn't mean that SCons shouldn't support the latest version of
>> Python available on the system.
>>
>> This is particularly troublesome for me as I consider putting together
>> a new build image, based on Debian 9, but with latest SCons installed
>> from source.
>>
>> I'm all for cleaning up old cruft, but it seems like removing support
>> for a version of Python that's less than 3 years old seems a bit
>> aggressive.
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Where does scons determine the dependencies for object files?

[Gary Oberbrunner]

>From a quick perusal of the source, I think the function you're looking for
is SCons/Node/__init__.py, Node.add_source(). That's called from
Builder._execute().

On Sun, Mar 25, 2018 at 2:05 PM, Andrew C. Morrow  wrote:

>
> Could you point me to where in the SCons sources that connection between
> foo.o and foo.c is made, exactly? I'd like to understand how it happens.
>
> Regarding pseudo-builders: they don't compose, unfortunately. Once
> something becomes a pseudo-builder it no longer exposes the attributes that
> normal builders do. So I'd prefer to achieve this by injecting
> scanners/emitters into the existing builders, if possible.
>
> On Sun, Mar 25, 2018 at 1:52 PM, Gary Oberbrunner 
> wrote:
>
>> The builder, in this case Object(), sets up the dependency between foo.o
>> and foo.c. The simplest way to do what you want is to create a
>> pseudo-builder that calls Object() and also calls Depends().
>>
>> -- Gary
>>
>> On Sun, Mar 25, 2018 at 1:07 PM, Andrew C. Morrow <
>> andrew.c.mor...@gmail.com> wrote:
>>
>>>
>>> I'm fairly clear on where SCons learns of the dependencies for source
>>> files: that is in the CScanner attached to the SourceFileScanner in T
>>> ool/__init__.py.
>>>
>>> But where does SCons determine the dependencies of object files, such
>>> that those dependencies are checked to see if the object file needs to be
>>> rebuilt?
>>>
>>> More concretely, If I have libfoo.so made from foo.o made from foo.c
>>> which depends on foo.h, the CScanner in SourceScanner takes care of
>>> scanning for dependences in foo.c and finds foo.h. But what scans for
>>> dependences of foo.o and identifies foo.c?
>>>
>>> I ask because I would like to sometimes inject a new source-like
>>> dependency into compilations, such that foo.o will depend on not just
>>> foo.c but also some other file magic, such that if magic is changed
>>> then foo.o will need to be rebuilt.
>>>
>>> With such a mechanism, it would be possible to teach SCons that if an
>>> AddressSanitizer blacklist file known to be on the compile line like
>>> -fsanitize-blacklist=path/to/magic is referring to a blacklist file
>>> that is more up to date than the object file, then the object file should
>>> be rebuilt.
>>>
>>> Thanks,
>>> Andrew
>>>
>>>
>>>
>>>
>>> ___
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>>
>>
>>
>> --
>> Gary
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Where does scons determine the dependencies for object files?

[Gary Oberbrunner]

The builder, in this case Object(), sets up the dependency between foo.o
and foo.c. The simplest way to do what you want is to create a
pseudo-builder that calls Object() and also calls Depends().

-- Gary

On Sun, Mar 25, 2018 at 1:07 PM, Andrew C. Morrow  wrote:

>
> I'm fairly clear on where SCons learns of the dependencies for source
> files: that is in the CScanner attached to the SourceFileScanner in T
> ool/__init__.py.
>
> But where does SCons determine the dependencies of object files, such that
> those dependencies are checked to see if the object file needs to be
> rebuilt?
>
> More concretely, If I have libfoo.so made from foo.o made from foo.c
> which depends on foo.h, the CScanner in SourceScanner takes care of
> scanning for dependences in foo.c and finds foo.h. But what scans for
> dependences of foo.o and identifies foo.c?
>
> I ask because I would like to sometimes inject a new source-like
> dependency into compilations, such that foo.o will depend on not just
> foo.c but also some other file magic, such that if magic is changed then
> foo.o will need to be rebuilt.
>
> With such a mechanism, it would be possible to teach SCons that if an
> AddressSanitizer blacklist file known to be on the compile line like
> -fsanitize-blacklist=path/to/magic is referring to a blacklist file that
> is more up to date than the object file, then the object file should be
> rebuilt.
>
> Thanks,
> Andrew
>
>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] [Scons-users] Feedback on issue creation template

[Gary Oberbrunner]

Which python distro (cpython, ActiveState, msys/cygwin etc. -- especially
on Windows)?

-- Gary

On Sat, Mar 17, 2018 at 2:17 PM, Eric Fahlgren 
wrote:

> Our procedure at work also calls for paragraphs on "what you see" and
> "what you expected to see".  The former is often some unexpected behavior
> or a stack dump, the latter is a short description of how you think your
> reproducer should work.  Of course, we don't vet things as well, users can
> just put in any old thing they don't understand, so your first item about
> "bring it to the list" probably minimizes some of what I've mentioned.
>
> On Sat, Mar 17, 2018 at 11:00 AM, Daniel Moody 
> wrote:
>
>> What about adding a requirement to paste the link to the scons users
>> archived thread in the submitted issue for reference and due process?
>>
>> On Sat, Mar 17, 2018, 1:54 PM Bill Deegan 
>> wrote:
>>
>>> Greetings,
>>>
>>> I've just added an issue creation template to Github.
>>>
>>> See it here:
>>> https://github.com/SCons/scons/blob/master/.github/issue_template.md
>>>
>>> If you have a moment to take a look and let me know if I've missed any
>>> information which should be provided when filing a new issue.
>>>
>>> Thanks,
>>> Bill
>>> SCons Project Co-Manager
>>> ___
>>> Scons-users mailing list
>>> scons-us...@scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] expected stdout error code format

[Gary Oberbrunner]

The 6,10d5 means lines 6 through 10 in stdout were in the expected output,
but not in the actual (at its line 5) (Or vice versa, not sure about order
of expected/actual there.)  That impenetrable message comes from diff.

On Sat, Dec 9, 2017 at 4:19 PM, Daniel Moody  wrote:

> Does anyone know how to interpret the error code for expected stdout?
>
> For example what does the '6,10d5' mean from this output?
>
> FAILED test of /home/travis/build/dmoody256/scons/src/script/scons.py
> at line 614 of /home/travis/build/dmoody256/scons/QMTest/TestCommon.py
> (_complete)
> from line 710 of /home/travis/build/dmoody256/scons/QMTest/TestCommon.py
> (run)
> from line 393 of /home/travis/build/dmoody256/scons/QMTest/TestSCons.py
> (run)
> from line 68 of test/exitfns.py
> STDOUT 
> =
> 6,10d5
> < running x3('no kwd args', kwd=None)
> < running x3(5, kwd='bar')
> < running x2(12)
> < running x1
> < running x3('no kwd args', kwd=None)
>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] [Scons-users] Github Project renamed from SConsProject to SCons

[Gary Oberbrunner]

Nice work Anatoly and Bill!

-- Gary

On Thu, Nov 23, 2017 at 6:05 AM, anatoly techtonik 
wrote:

> Awesome. ) More proposals from my side.
>
> 1. SCons repos need `scons` label to compete in this list:
> https://github.com/topics/scons
>
> 2. SCons website need to be moved to GitHub as well:
> https://bitbucket.org/scons/scons-new-website
> https://bitbucket.org/scons/scons-website
>
> This should probably be killed:
> https://bitbucket.org/scons/scons-pelican-bootstrap3
>
> On Wed, Nov 22, 2017 at 10:00 PM, Bill Deegan 
> wrote:
> >
> >
> > On Wed, Nov 22, 2017 at 9:46 AM, Bassem Girgis 
> wrote:
> >>
> >> This is great news. I would recommend consolidating all the online
> >> references to the new repo. Also what is the role of the bitbucket
> repo? The
> >> user contribution builders also need some sorting. I would be more than
> glad
> >> to help in any activity.
> >
> >
> > Where are you seeing references to the bitbucket repo?
> > Most likely they should all be changed.
> >
> > At this point the bitbucket repo is just historical.
> > There are some outstanding pull requests which have yet to be migrated to
> > github.
> >
> > -Bill
> >
> >>
> >>
> >> Best regards,
> >> Bassem
> >>
> >> 
> >> Bassem Girgis, PhD
> >> Cell: +1(256)479-6124
> >>
> >> On Nov 22, 2017 10:48 AM, "Eric Fahlgren" 
> wrote:
> >>>
> >>> Special thanks to you, Bill, and all the others for reviving SCons and
> >>> bringing it back to active life!  It made my life so much easier being
> able
> >>> to continue using SCons as part of our migration to Python 3.  I had
> been
> >>> right at the start of attempting to convert our build system over to
> CMake
> >>> when the stable 3.0 port came out, which saved me untold hours (or
> days or
> >>> weeks) of converting our build system, some parts of which are almost
> 20
> >>> years old now.
> >>>
> >>> Eric
> >>>
> >>> On Wed, Nov 22, 2017 at 7:11 AM, Bill Deegan <
> b...@baddogconsulting.com>
> >>> wrote:
> 
>  Special Thanks to Anatoly for tracking down the previous owner of
>  "SCons" and asking him to change thus freeing up SCons.
> 
>  Special Thanks to Steve Constable (formerly SCons on github) for
>  changing his github user id to free up SCons!
> 
>  You will have to update your remote settings under git.
> 
>  Assuming "upstream" was the remote name you're using to point at the
>  master SCons repo, the following command will update your git sandbox.
> 
>  git remote set-url upstream g...@github.com:SCons/scons.git
> 
>  I'll be updating various bits of SCons wiki, buildbot, and website
> today
>  to make sure they are all pointing at the proper (changed) URLs.
> 
>  -Bill Deegan
>  SCons Project Co-Manager
> 
> 
> 
> 
>  ___
>  Scons-dev mailing list
>  Scons-dev@scons.org
>  https://pairlist2.pair.net/mailman/listinfo/scons-dev
> 
> >>>
> >>>
> >>> ___
> >>> Scons-users mailing list
> >>> scons-us...@scons.org
> >>> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >>>
> >>
> >> ___
> >> Scons-users mailing list
> >> scons-us...@scons.org
> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >>
> >
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
>
>
>
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] [Scons-users] SCons 3.0.0 release

[Gary Oberbrunner]

Congratulations!! Huge step forward!

On Tue, Sep 19, 2017 at 3:17 AM, Dirk Baechle  wrote:

> This is awesome! Thanks so much for pushing this through, Bill!
>
> Dirk
> --
> Sent from my Android with K-9 Mail.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] D tool development workflow

[Gary Oberbrunner]

Ha, I can hardly call myself a "core activist" anymore, but thanks. :-)

On Fri, Apr 21, 2017 at 1:28 PM, Russel Winder  wrote:

> On Fri, 2017-04-21 at 12:55 -0400, Gary Oberbrunner wrote:
> >
> […]
> >
> > I would be so happy about this. I would gladly volunteer to help. I'm
> > all
> > git+github for literally everything else, home & work.
>
> I think I have been tainted by Apache do-ocracy from association with
> Apache Groovy: to those that do is given the power to decide.
>
> Given that the two core activists want change form Mercurial to Git,
> then that change should happen.
>
> --
> Russel.
> 
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] D tool development workflow

[Gary Oberbrunner]

On Fri, Apr 21, 2017 at 12:41 PM, Bill Deegan 
wrote:

> That said, I'm thinking post 3 a migration to github could have some real
> value.
> (And git, I'm tired of using HG on only this project)


I would be so happy about this. I would gladly volunteer to help. I'm all
git+github for literally everything else, home & work.


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] [Scons-users] Can we drop windows native installers if pip install works?

[Gary Oberbrunner]

As a Windows user, I'd be very happy if pip install were the only proper
way to install it going forward. Yes, sometimes I'd want to do it locally,
but using pip is fine.

On Mon, Apr 10, 2017 at 8:15 AM, Jonathon Reinhart <
jonathon.reinh...@gmail.com> wrote:

>
> On Mon, Apr 10, 2017 at 3:36 AM, Alexandre Feblot <
> alexandre.feb...@gmail.com> wrote:
>
>> And in some controlled environments, there might be no access to
>> internet. A self contained installer is still the best solution in this
>> situation.
>
>
> That's not an issue. Pip will happily install from a zip file, tarball,
> cloned git repo, etc. There is no internet access requirement to use Pip.
>
> A lot of Windows users will, out of habit, come looking for "setup.exe",
> but considering Pip comes pre-installed with Python 2.7 and up these days,
> it'd be trivial to 'pip install scons'.
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Accommodating dependency cycles.

[Gary Oberbrunner]

On Wed, Mar 22, 2017 at 10:47 PM, William Blevins 
wrote:

> Here is another one. I assume this round of issues is because they updated
> SCons on the latest Ubuntu. This one actually makes sense. Someone else
> posted this one. "test2.h" explicitly depends on "test.h" via Command
> Builder, and "test.h" implicitly depends on "test2.h" via scanner.


except not quite: the scanner makes (or *should* make) anything *compiled
from* test.h (e.g. test.obj) depend on test2.h. test.h has no dependencies;
it's a source. As perhaps you noted above, it seems like the Command
builder is somehow running the C scanner, but shouldn't. If the Command in
this example had been an Object or Program whose target was still called
test2.h, then there would be a real dependency loop (because test.h
includes test2.h, SCons shouldn't compile test.h into the result object
until test2.h is up-to-date, and the result "object file" in that case is
called test2.h).

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Accommodating dependency cycles.

[Gary Oberbrunner]

On Wed, Mar 22, 2017 at 6:15 PM, William Blevins 
wrote:

> //source.cpp
> #include "source.gen.h"
> int main() { return 0; }
>
> //SConstruct
> e = Environment()
> e.Command("source.gen.h", "source.cpp", Copy('$TARGET', '$SOURCE')) #
> "generator"
> e.Program("source.cpp")
>
> This code works fine in Scons 2.1, but Scons 2.5.1 produce error:
> scons: *** Found dependency cycle(s):
>   source.gen.h -> source.gen.h
>
> If I'm reading this correctly, I don't see a cycle.
"source" depends on source.cpp and source.gen.h.
source.gen.h depends on source.cpp.
source.cpp is a source, doesn't depend on anything.
Now source.gen.h includes itself, which is weird, but shouldn't all by
itself cause a loop as long as the scanner knows it's already seen that
file.
source.gen.h should definitely not depend on itself.

(Not saying the current code doesn't detect a cycle, just that in the
abstract there shouldn't actually be one.)


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Proposal for SCons documentation on StackOverflow...

[Gary Oberbrunner]

Looks like I was the final vote!

On Jul 30, 2016 7:35 AM, "Dirk Bächle"  wrote:

> Hi there,
>
> for the beta phase of the new StackOverflow documentation, SCons is now
> also proposed...to make this happen we need 5 committers accepting the
> proposal. Two (myself included) have already given their vote, and it would
> be cool if anyone who's active in StackOverflow clicks the "Commit" button
> too.
>
> As far as I understand it, this doesn't mean that the accepting person has
> to actively participate in writing and maintaining SCons documentation, but
> supports the idea in general.
>
> Here's the direct link:
>
>   http://stackoverflow.com/documentation/scons/commit
>
> and thanks in advance for your contribution.
>
>
> Best regards,
>
> Dirk
>
>
> P.S.: My idea behind this is to actively use StackOverflow to collect
> simple examples and usage schemes, that could then get added to the
> UserGuide later on, if appropriate. Further, it would lower the barrier for
> people that don't want to deal with our documentation toolchain. Having to
> tackle only standard markdown syntax should bring forth a number of
> contributors in the area of documentation. This will definitely help the
> project in the long run... ;)
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] no more print statements in SConscripts?

[Gary Oberbrunner]

Hi folks; I know I've been out of the loop recently, lots going on. Great
work getting the python 3 stuff in!

I did just try the default branch (with python2.7 on Windows) and I notice
print statements (not the function, just the statement) in
SConstructs/SConscripts are now syntax errors. This'll probably be a big
change for users. Just FYI.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Hg vs Git

[Gary Oberbrunner]

It would certainly make it easier for me to contribute; not that I've had
that much to contribute recently, but git is in my fingers now and I have
to remind myself how to do things in hg.

On Mon, May 9, 2016 at 1:13 PM, Bill Deegan 
wrote:

> All,
>
> So it sounds like (from limited consensus), that switching to Git now,
> would remove a significant barrier to contributing code/fixes?
>
> -Bill
>
> On Mon, May 9, 2016 at 8:12 AM, Tim Jenness  wrote:
>
>>
>> > On May 9, 2016, at 07:57 , Rob Boehne  wrote:
>> >
>> > For me, scons is the ONLY project I work on that uses Mercurial, and
>> > having to translate each and every command is a real pain.
>> > I¹ve also NOT contributed back many changes I¹ve made to get Python to
>> > build properly on old UNIX systems, primarily because it was using Hg.
>> >
>> > I doubt I¹m alone in this, and I¹m certain it¹s a lot easier to find a
>> > competent developer who knows Git but has never used Mercurial than the
>> > other way around.  This is an extra effort for most developers, and that
>> > extra effort will get more common, and more painful as the years go by.
>> > IMHO switching to Git is a clear win.
>> >
>>
>> I have to agree. Whilst I am really interested in helping with the python
>> 3 port the hg hurdle has just meant I haven’t found the time. I have too
>> many other things pulling at me that I can do easily with my git workflow.
>>
>> —
>> Tim Jenness
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Python 3 strategy

[Gary Oberbrunner]

On Mon, Jan 25, 2016 at 4:39 AM, Russel Winder  wrote:

> The alternative is to abandon the current python3-port and start again
> from default based solely on future.
>

This doesn't seem crazy to me, although there was a LOT of hand-tweaking of
code on the current python3 branch: utf8/locale stuff, print stmts, which
in a fair number of cases didn't look like any automation would've caught
them. So if you start again I suspect most of that work will have to be
redone. I spent a couple of days on it, iirc, and I wasn't the only one.
Maybe some of those changes could be cherry-picked over? I suggest skimming
some of my changes on that branch (not the merges, just the by-hand stuff)
to get a sense of what had to be done.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Python3 activity

[Gary Oberbrunner]

On Fri, Jan 15, 2016 at 8:24 AM, Russel Winder  wrote:

> Aim is still to get the code-base working properly, i.e passing all
> tests, as a Python 2.7 program, so that it can then become the default
> branch. My thinking here is that if we do not have a separate branch,
> but instead are evolving default to be Python 3 compatible as a Python
> 2.7 codebase then Python 3 usage will happen faster. The "down side" is
> that all Python 2 code must be written with Python 3 compliance from
> merge time on on, this includes all pull requests.
>
>

I'm absolutely in agreement with this as our forward-looking plan, once the
initial hump is surmounted.


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] new website update and added badges to readme for repo

[Gary Oberbrunner]

LGTM!

On Thu, Jan 14, 2016 at 2:10 PM, Bill Deegan 
wrote:

> All,
>
> If you get a chance, take a look:
> http://scons.org/new/
> and
> https://bitbucket.org/scons/scons
>
> The badges take a few seconds to render (on my currently very crappy
> internet connection)
>
> Unless I hear lots of reasons not to, I'm going to roll out the new
> website over the weekend.
>
> -Bill
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Trial SCons migration to git on github

[Gary Oberbrunner]

On Sun, Jan 10, 2016 at 4:26 AM, Dirk Bächle  wrote:

> On 09.01.2016 20:47, Bill Deegan wrote:
>
>> Dirk,
>>
>> For me, its "pain in having to remember how to do things in mercurial
>> which I only use for scons" each time I go to work on it I
>> have to refresh my mental cache.
>> Which I'm pretty sure wouldn't be measurable by such statistics. But (at
>> least for me) would increase the amount of fun it is to
>> work on the project.
>>
>>
> and this (I'm referring to the "increased fun" here) wouldn't result in
> "more commits" and "more bugfixes"? Jonathon Reinhart stated this point in
> his mail explicitly: more git -> more commits.


This is my situation as well -- SCons is the only project I contribute to
that still uses hg, and since I use git everywhere else I've become pretty
expert at it. It's in my fingers and I don't even think about it anymore. I
also have dozens of git aliases and config tweaks so I go pretty fast with
it. There is of course also the better data model, but of course that's
arguable so I'm only mentioning my personal situation -- but I suspect I'm
not unique. So would switching lead to more commits and bugfixes? I can't
say for sure but from what I've seen in hiring developers, almost everyone
knows git and puts it on their resume, and I only rarely see hg experience.
So it _might_ make it easier for other contributors.

As for using a git-hg bridge, that would help local usage for us git users,
but it doesn't change the underlying branching model. If it's decided not
to switch, I might consider trying that.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Rumour…

[Gary Oberbrunner]

On Wed, Jan 6, 2016 at 1:55 PM, Bill Deegan 
wrote:

> I'm of the opinion that there's no need to address the bug tracker at the
> same time as move the repo and/or hg->git.
> I only use hg for scons, git for everything else.


I agree.


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Code of conduct?

[Gary Oberbrunner]

It's OK with me. As I said at the beginning I'd prefer something broader
and less specific but I didn't find anything useful.

On Tue, Dec 29, 2015 at 2:29 PM, Bill Deegan 
wrote:

> All,
>
> So are we good with:
> http://contributor-covenant.org/
>
> If so I'll add it to the new website.
>
> -Bill
>
> On Tue, Dec 29, 2015 at 12:39 AM, Dirk Bächle  wrote:
>
>> Anatoly,
>>
>> Am 28.12.2015 um 15:33 schrieb anatoly techtonik:
>>
>>> [...]
>>>
 I'm not sure why you're objecting to this unless you think you are
 likely to
 violate a CoC..

>>> Because following CoC makes people CoC-followers, which is offensive for
>>> some. Don't be a jerk rule is good enough and the rules should be applied
>>> only when they are needed on personal basis.
>>>
>>> I am against CoCs. It makes me feel regulated and I am sick and tired of
>>> that,
>>> so I likely to act against it and you have to ban me.
>>>
>> feel free to "act against it", but "filibustering" (refer to
>> http://www.merriam-webster.com/dictionary/filibuster and optionally
>> https://www.youtube.com/watch?v=Q52kFL8zVoM ) won't help. We've already
>> reached consensus to have a simple CoC and are simply ironing out the last
>> details.
>>
>> @all: Are we ready to move on with this one and take some action? I am...
>>
>> Best regards,
>>
>> Dirk
>>
>> P.S.: Nobody wants to ban you. We'll simply continue with our plan and
>> are ready to face the consequences of you getting "sick and tired" about
>> feeling regulated again...
>>
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons and Python 3

[Gary Oberbrunner]

Hi Russel; last time I did this it wasn't all _that_ painful. Took a few
hours if I remember rightly. (Of course a lot of time has passed, but still
not that much new code compared to the entire code base.) Look at the diff
of the last merge before you start, to get a sense of the top two or three
things that have to get tweaked.

On Sat, Dec 19, 2015 at 4:39 AM, Russel Winder  wrote:

> On Wed, 2015-12-16 at 09:22 +0100, Dirk Bächle wrote:
> >
> […]
> > @Russel: If all Buildbots turn out to be "green", feel free to merge
> > onto the python3 branch...
>
> It appears as though Windows is still a bit red, but I cannot in all
> honest profess any sadness. As all the Linux variants are green, I
> shall take this as a "go" to do a merge to the Python 3 branch. This
> will undoubtedly lead to a right royal mess, but then that is the whole
> point – fix the mess.
>
> My assumptions will be:
>
> Python 3.4 and 3.5
> Python 2.7.10
> Debian Sid
> Fedora Rawhide
> No packages not in the standard distribution
> A lack of CI to cover Solaris, OSX or Windows
>
> I may be gone a while…
>
> Progress will be reflected in  https://bitbucket.org/russel/scons__pyth
> on3
>
> Should anyone track progress and want to chip in feel free. If you see
> any lack of progress, it will either be me having to work on organizing
> ACCU 2016 (accu.org) or choosing to work for a while on GPars or Me TV
> – or eating and especially drinking, it is Christmas after all. Do not
> drink and code.
>
> --
> Russel.
>
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Code of conduct?

[Gary Oberbrunner]

I don't see it that way. I see it as a proactive, positive step.

Look, right now there's a lot of, well, not-so-nice people in the world.
Many of them hang out online. This isn't PC, it's a fact of modern life.
This isn't going to get better; I think it's getting worse if anything.
Saying "hey, we're a friendly and welcoming community" isn't pandering,
it's accepting that not everyone is nice, but saying we aim to be.

At least that's my 2 cents.

On Thu, Dec 10, 2015 at 6:55 AM, Russel Winder  wrote:

> I think there is an element of needing to pander to the culture of
> political correctness. Some events and communities have had bad
> processes and attitudes. Those needed to impose a CoC to try and amend
> the behaviour of the not so nice element. However this has now become a
> tool for labelling communities good or bad. If you do not have a COC
> you are clearly a bad (sexist, racist, ,…)
> community because you do not have a CoC. Thus, there is now a need to
> have a CoC to avoid the marketing pressure of the political correctness
> police.
>




-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Code of conduct?

[Gary Oberbrunner]

Indeed. I think the discussion so far points to let's have one, keep it
short & sweet. I don't see any real reasons not to, and some possible
benefits to having one.

On Tue, Dec 8, 2015 at 2:57 PM, Bill Deegan 
wrote:

> Anatoly,
>
> In the entire history of SCons we've only had a small handful of instances
> where any of the proposed CoC's might have been violated.
> So infrequent I can't remember the last one.
>
> That said, if you can prove harm or point to any project where it harmed
> their community to have a CoC, then I (and I expect the rest of the SCons
> developer list) would be interested in such.
>
> Nothing you've said thus far has been convincing to me (nor it seems any
> other community member).
> Otherwise it is speculation.
>
> I can say for certain that some organizations expect such when providing
> grant money to open source communities.
> For me that's sufficient reason.
>
> I will also say that if the SCons project finds that having a CoC is
> damaging to it's community, then we'll revise or revoke it as appropriate.
> (where damaging doesn't equal one person is being unreasonable or abusive
> and doesn't like having the fact that their behavior violates the CoC, but
> does equal contributions to the project including features and/or bugfixes
> and/or docs slow to a standstill, and/or usage of SCons diminishes in a
> meaningful way measurable to the adoption of a CoC).
>
> -Bill
>
> On Tue, Dec 8, 2015 at 2:10 PM, anatoly techtonik 
> wrote:
>
>> On Tue, Dec 8, 2015 at 8:02 PM, William Blevins 
>> wrote:
>> > On Tue, Dec 8, 2015 at 2:59 AM, Bill Deegan 
>> > wrote:
>> >>
>> >> An extra 2cents of opinion from me.. ;)
>> >>
>> >> A few things a CoC would help with:
>> >> 1) It could encourage more participation on the mailing lists. Open
>> source
>> >> projects have been notorious for scathing responses to simple
>> questions.
>> >> Surprisingly I've been at clients who have used SCons for years and
>> never a
>> >> single member of their staff has asked a question on the mailing
>> list.. I
>> >> was shocked.
>> >
>> >
>> > I don't think this attitude is uncommon.  Many of my past coworkers view
>> > interacting on forums and mailing lists as a "hassle", and they would
>> rather
>> > try to brute force since they "know" best. I'm not sure this can be
>> helped.
>> > unfortunately.
>>
>> I agree. Businesses discourage people from spending time on forums. They
>> can only understand it if they pay money for it. Also not many companies
>> want outside World to know that they can't do something themselves.
>>
>> So, if business people want straightforward and nice discussions, let them
>> pay for it. Otherwise there is conflict that those of us who volunteers
>> and
>> are not being paid should behave well in order to provide free service for
>> those who don't care.
>>
>> The paragraph above is an example that CoC doesn't solve anything, because
>> it doesn't remove causes of conflicts.
>>
>> --
>> anatoly t.
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Code of conduct?

[Gary Oberbrunner]

I'm in favor of something like this. It's really important to be a
welcoming and inclusive community. I don't think having a code of conduct
is any kind of admission of failure; rather I see it as a proactive
statement of inclusiveness and professionalism. I wonder if a broader code
of conduct wouldn't make sense as well, covering general ethics
(intellectual property, honesty, integrity, objectivity, humility,
transparency, conflicts of interest, etc.) and professional behavior as
well as some of the specific coverages in the CC? Anyone know of examples
of such things that might apply to a group like ours? Of course lawyers,
doctors, and engineers have such codes but they tend to be lawyery and
overdone. I'd almost be in favor of just "don't be a jerk" but I think that
doesn't work for the people it most needs to work for. What about e.g.
http://yahoo.github.io/codeofconduct?

On Fri, Dec 4, 2015 at 12:10 PM, Bill Deegan 
wrote:

> All,
>
> Perhaps it's a good idea to add an official code of conduct for SCons.
>
> http://blog.codinghorror.com/the-hugging-will-continue-until-morale-improves/
>
> The following site seems to provide a reasonable code.
> http://contributor-covenant.org/
>
> Thoughts?
>
> -Bill
> p.s. as an aside I also work on Buildbot and they applied for an open
> source grant through Mozilla's $1M grant program. One of the questions was
> "Do you have a code of conduct".
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Configure(), dependencies, and Variant dir

[Gary Oberbrunner]

Does anyone know how these interact?

I have a TryBuild test in a Configure context. It uses a variant dir. The
.c file in the test includes foo.h, which includes bar.h. If I have a
previous build (which copied bar.h into variantdir) and then update bar.h,
the TryBuild uses the old variantdir/bar.h without copying the new version
to the variant dir first as it should. The regular part of the build works
fine, it's just the SConf part.

I suspect something in the dependency tracking logic isn't fully
implemented in configure context; does this seem familiar to anyone before
I dig into it further?

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Python 3 branch

[Gary Oberbrunner]

I didn't think it had been that long... I'll check my records.

On Sat, Nov 7, 2015 at 3:20 AM, Russel Winder  wrote:

> Gary,
>
> From what I can see the last merge from default into python3-port was
> 2014-08-23. A lot has happened since then. :-)  Is the best way forward
> to do a merge, deal with the fall out, and see where we are?
>
> --
> Russel.
>
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Unit testing with mock?

[Gary Oberbrunner]

Python mocks are extremely useful. We use them in my day job and
unit-testing that code would be pretty hard without them. The main
counterargument to using them in SCons is that it introduces a dependency,
and to date SCons can build and test with no external dependencies. But of
course that's not _really_ true: many SCons tests test compilers and tools
that are often not present, so those tests get skipped.That's one route you
could take: if no mock module exists, skip the tests. But another way this
has been done in SCons in the past is to copy the module into SCons, e.g.
in the src/engine/SCons/compat subdir, with appropriate name changes. If
the module in question's license permits this, and it's self-contained, why
not do this? In this case it'd probably want to be under QMTest but the
principle is the same.

Quoting from src/engine/SCons/compat/__init__.py:

*This subpackage holds modules that provide backwards-compatible*
*implementations of various things that we'd like to use in SCons but which*
*only show up in later versions of Python than the early, old version(s)*
*we still support.*


Other devs, what do you think?

On Fri, Oct 23, 2015 at 12:27 PM, Paweł Tomulik 
wrote:

> This is the module I'm currently working on:
>
> https://github.com/ptomulik/scons-arguments
>
> for the moment 'devel' branch is more recent:
>
> https://github.com/ptomulik/scons-arguments/tree/devel
>
> Mocks are used in unit tests:
>
>
> https://github.com/ptomulik/scons-arguments/blob/master/unit_tests/SConsArgumentsTests.py
>
> It's hard to tell what's the particular purpose of using mocks for a
> particular project. It's rather a choice of testing philosophy. Mocks
> always play same role: to isolate the behaviour of the object (or
> method) being tested on other objects (or methods). That way less tests
> get affected when a particular object changes its behaviour.
>
>
> W dniu 23.10.2015 o 16:19, Bill Deegan pisze:
> > Pawel,
> >
> > If the plan was to migrate SCons to 3.x and drop support for 2.7, then
> > maybe using mocks would be ok now.
> > But the plan is to support both for some time once we get SCons working
> > with 3.x.
> >
> > What are you using mocks for now? Can you point to a repo?
> > Note that thus far, the mocks module has not been used, so chances are
> > it can be done without additional modules (though perhaps with more
> code).
> >
> > -Bill
> >
> > On Fri, Oct 23, 2015 at 1:56 AM, Paweł Tomulik  > > wrote:
> >
> > So, what should I replace my existing mocks with? Do you know any
> > technique?
> >
> > These mocks would only be required for unit-testing scons package, so
> > this doesn't affect plain users (only developers and scons package
> > maintainers would be affected). And starting from 3.3, the mock
> module
> > is part of python standard.
> >
> >
> >
> > W dniu 23.10.2015 o 09:21, Alexandre Feblot pisze:
> > > Hi,
> > > Please, please, please,
> > > Don't!
> > > Don't force people to install additional modules.
> > > One of Python benefits is how rich its standard distribution is,
> > compared to perl for example, allowing to distribute code that you
> > know will work everywhere without additional requirement.
> > > Please don't break that.
> > >
> > > Alexandre
> > >
> > >> Le 22 oct. 2015 à 23:58, Pawel Tomulik  > > a écrit :
> > >>
> > >> Hi,
> > >>
> > >> If I would like to contribute a module to scons, would it be
> > acceptable
> > >> to use mocks (https://pypi.python.org/pypi/mock) in unit tests?
> From
> > >> what I see, none of the existsing unit tests in SCons use mocks,
> > perhaps
> > >> for a reason? Is it forbidden? Is there an alternative without
> > using the
> > >> module?
> > >>
> > >> The mock module is not included in the basic python distribution,
> > it has
> > >> to be installed, for example with pip (it's a backport of
> > unittest.mock
> > >> available in python >=3.3).
> > >>
> > >>
> > >> Best regards!
> > >>
> > >> --
> > >> Paweł Tomulik
> > >>
> > >> ___
> > >> Scons-dev mailing list
> > >> Scons-dev@scons.org 
> > >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> > > ___
> > > Scons-dev mailing list
> > > Scons-dev@scons.org 
> > > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> > >
> >
> >
> > --
> > Paweł Tomulik, tel. (22) 234 7925
> > Instytut Techniki Lotniczej i Mechaniki Stosowanej
> > Politechnika Warszawska
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org 
> > https://pairlist2.pair.net/mailman/listinfo

Re: [Scons-dev] SCons tools refactoring progress

[Gary Oberbrunner]

You talk a lot about what I consider "policy": specific types of args that
would be used to configure specific types of Tools, like compilers. This is
all fine, but my goal is to build a framework where such policies can be
applied, and then get into the specifics of platforms, cross-compilers,
versions, targets and all that. Building a game asset manager, or a
visual-effects pipeline, or a document-preparation system, or a
scientific-data analysis pipeline, will have very different _specifics_ but
the same general mechanism should be usable for all, or at least that's my
goal.

Jason, since you've already been down this path once, I'd very much
appreciate a code and design review of what I have so far. It's only 700
lines or so, including tests. I'm especially interested in use cases Parts
can handle that my proposed system wouldn't be able to. (Again, from a
mechanism or base framework standpoint; not that I don't specifically
define a target architecture argument for instance.)

One use case I see from your notes below is this one, which I'll capture:
  As a SConscript writer, I'd like to be able to enumerate all versions of
a tool on the system so I can choose which one to use.
If there are others, please send them along.

-- Gary

On Tue, Oct 20, 2015 at 11:39 AM, Jason Kenny  wrote:

> Hi Gary,
>
>
>
> From looking at the below this seems to be in line with what is going on
> in Parts.  I had hoped that what I did here would be used /improved on in
> Scons. That is the a goal of Parts.. to improve Scons.
>
>
>
> From what you talk about below I think we are in general on the same page.
> I know when I started this I was also of the view that the “args” should be
> external. At the time Steve Knight release pushed hard that all value could
> be defined in the environment. I see some value in this, however I was like
> you in which I wanted to have something separate to define arguments to
> setup a tool. I also wanted to have a standard set of values. For example
> we should use the same values to talk about archecture, version, etc.. when
> we can as this makes it easier to use and develop new tools. Given what I
> have seen in practice, I was moving towards the IATAP idea from Greg. This
> is what I call Settings in Parts. While I have not finished this object yet
> I think it goes toward this idea better. Here we have an object that given
> values creates an environment to be used to build stuff. I think at a high
> level we want to move this way.
>
>
>
> For a design of the tools I think these are items we want to understand
> and define some way.
>
>
>
> *Platform*- Parts define a system platform object, Scons defines a
> string, for the OS, it has nothing standard for the architecture. I think
> we should agree we need to define this better in Scons. I would like to see
> something in Scons defining this. I suggest what I have in Parts as a way
> to start. I define in a given environment a HOST_PLATFORM object and a
> TARGET_PLATFORM Object. This is to extend the PLATFORM string we have now.
> The way I did in in Parts allows these items to be synced and to extended
> with new os or archecture value at run time. I think having something like
> this in SCons will allow for a better more reusable tool design.
>
>
>
> *Finders*- In Parts I have Finders and Scanners. These are different in
> what they return, but in effect are the same thing. I believe in the case
> of what Gary is talking about in Scons they serve the same purpose. The
> goal is it to return if we found something at a given resource location,
> given that being a path, registry entries, or environment variable. I
> should point out in someway this is like a autoconf test to find a
> compiler, etc. I would like to think this way is better however. I Parts I
> have finders and scanners. The difference in Parts is that a scanner
> returns back a set of value with version information, where a finder is
> much more simple “We have a match as resource X”. The reason for the
> difference is that some tools are easier to find as a set vs defining every
> known case. For example when I worked at Intel, the Intel compiler would
> make lots of internal drops as one would expect, these drops would have
> different versions. People would want to test the new drops out. Instead of
> me making a new entry for each new drop, I scanned the disk for example for
> what was installed. And returned all versions installed on disk. This
> scaled better for this tool set for users. Another example ( which I should
> improve a bit more) is the GNU tool change. People can install different
> version of the compiler on a Linux system and they often install them in
> different ways, such as under /opt or in there home directory in a standard
> way. I tried to have the Gnu logic in Parts look for these common places
> and use these version of requested. The use of a scanner logic was a lot
> easier here than making lots of custom finders. The main value of a f

Re: [Scons-dev] SCons tools refactoring progress

[Gary Oberbrunner]

Comments inline.

On Tue, Oct 20, 2015 at 12:52 AM, anatoly techtonik 
wrote:

> On Tue, Oct 20, 2015 at 3:57 AM, Gary Oberbrunner 
> wrote:
>>
>> On Sun, Oct 18, 2015 at 7:52 AM, anatoly techtonik 
>> wrote:
>>
>>>
>>> I see the implementation, but I don't see any use cases. I know it
>>> sounds too formal, but I can't validate the assumptions we had towards the
>>> new toolchain without a formal list. Do you have some notes or maybe BDD
>>> tests for that?
>>>
>>
>> A very good question. I don't have enough design notes in there; I'll
>> write up some of my motivations and design goals here and add them to the
>> README.rst.
>>
>> The basic idea is that the current concept of a Tool is too low level;
>> the primary motivating use case is that users (SConscript authors) should
>> be able to select groups of related tools, _as_ a group, with fallbacks. A
>> Toolchain is that abstraction.
>>
>
> The use case is already good to be recorded. But there are two cases:
> 1. Select a group of related tools
> 2. Fallback
> Do we have a concrete groups of related tools already?
>

Yes, I described a few. (Compiler and linker, maybe assembler is the
obvious one.)


> The fallback story needs to be expanded. Are there fallback choices inside
> of one group (with priority or other preference strategy) or the fallback
> means "fallback to another group"? Maybe I am too detailed, but also - what
> are the cases when fallbacks occur?
>

This is all implemented. Check the code and test cases (Toolchain-test.py).
I think it's pretty solid but please review. Basically it's recursive AND
and OR trees with optional or required elements.


> It it not necessary to design everything now upfront - the primary goal of
> my questions is to find *real world* stories (not even use cases) for which
> new mechanism is needed. I am afraid to design a system that will be too
> perfect for implementation in a free time.
>

Well, at least for the toolchain, I think it's mostly there
implementation-wise (check it out). The interesting stuff is improving the
Tool ideas (there's a sort of registry so you can give concrete tools names
and look them up that way), adding Finders, and all the other stuff that
we've been discussing. But if you have some real-world stories you'd like
to see covered, this is a good time to get them out there.

All the rest is just there to make that idea work well. The secondary goal,
>> in service of the main one, is that Tools need to obey their abstraction,
>> for instance always calling exists().
>>
>
> What is the story behind this? Because I know the opposite story -
> exists() for default tools is called even if I don't build anything with
> those tools - this delays the build start and produces messages about
> missing compiler to the screen.
>

exists() is how a tool knows whether its binaries (or whatever it needs to
run) exist or not, so toolchains can't work without it. As for default
tools, the idea here is that SConscript writers will (finally!) be able to
specify exactly which tools they want. I hope to do away with the current
default tool initialization system, though some of that still needs to be
thought out. The current design is much "lazier" but still needs work.

The new system also creates a distinction between an abstract tool, such as
>> intelc, and a concrete instance of it, such as intelc v12 x86. This is
>> needed so the user can create chains of either specific or general tools.
>>
>
> I understand where this might be useful, but still - is there a real world
> story where this was needed?
>

Absolutely - in my day job we specify very carefully what tool chain is
used to build any given product. If the machine doesn't have the right
version of the Intel compiler the build should fail. For open-source
projects, on the other hand, they should try to build on as many
configurations as possible so they want to keep things general -- use any
Intel compiler, or any gcc, or any cc (for instance).


> One restriction I'm imposing in the new system is that Tools have to be
>> configurable outside of any Environment; I don't like the current system
>> where tool-configuration variables ("tool args" basically) are mixed into
>> the Environment. This poses some challenges for a fully generalizable
>> system but I think I have a decent handle on that. The current Intel
>> compiler has an initial attempt at such tool args.
>>
>
> How to handle "tools args" is a question for a separate thread. We will
> need to have a standard set for every *type* of tool and specific for every
>

Re: [Scons-dev] SCons tools refactoring progress

[Gary Oberbrunner]

On Sun, Oct 18, 2015 at 7:52 AM, anatoly techtonik 
wrote:

>
> I see the implementation, but I don't see any use cases. I know it sounds
> too formal, but I can't validate the assumptions we had towards the new
> toolchain without a formal list. Do you have some notes or maybe BDD tests
> for that?
>

A very good question. I don't have enough design notes in there; I'll write
up some of my motivations and design goals here and add them to the
README.rst.

The basic idea is that the current concept of a Tool is too low level; the
primary motivating use case is that users (SConscript authors) should be
able to select groups of related tools, _as_ a group, with fallbacks. A
Toolchain is that abstraction. All the rest is just there to make that idea
work well. The secondary goal, in service of the main one, is that Tools
need to obey their abstraction, for instance always calling exists(). The
new system also creates a distinction between an abstract tool, such as
intelc, and a concrete instance of it, such as intelc v12 x86. This is
needed so the user can create chains of either specific or general tools.
One restriction I'm imposing in the new system is that Tools have to be
configurable outside of any Environment; I don't like the current system
where tool-configuration variables ("tool args" basically) are mixed into
the Environment. This poses some challenges for a fully generalizable
system but I think I have a decent handle on that. The current Intel
compiler has an initial attempt at such tool args.

Some use cases:
 * a simple SConstruct should automatically select the "best"
compiler/linker
 * a non-C-related SConstruct (e.g. doc prep, asset management, scientific
data handling) shouldn't have to care about compilers, linkers or other
unrelated tools
 * a SConstruct author should be able to specify toolchains and
alternatives, and handle failures gracefully
 * it should be possible to write a SConstruct where the tools and
toolchains can be manipulated by cmd line args if desired
 * it should be possible to specify desired tools generally ("gcc/gnulink")
or very specifically ("gcc 4.3, x86 cross compiler, with gnulink 4.3 - and
TeXLive")

There's a bunch of tests in that dir; they're mostly unit-test level at
this point. There are also some examples of the new subsystem in use (see
the README) which are closer to actual use cases.

My current task is to design a good way for Tools to find their executables
and configure themselves. The current ad-hoc method is not consistent and
doesn't encourage reuse. Jason has some ideas in Parts (see its concept of
Finders); I don't intend to reuse that directly but at least take some
inspiration from it. My current design I'm working on is something like
this: ... a good architecture might be to have a list of finders, to be
tried in order; each one can be any type (env, reg, path, fixed path,
function, whatever); build a list of all the results, and then have a
finder-picker that picks the best from that list (the simplest
finder-picker might be return paths[0]). But where that list comes from and
how it's manipulated is still TBD.

Additionally I'd like to see how far it makes sense to go in having
standard args to configure Tools; one way is just to leave args up to each
Tool (but maybe have the Finders have some high-level control); the other
is to define many standard ones (like ARCH, search in PATH or some custom
path, and so on) - the latter will make it easier someday to pass these all
the way down from the cmd line. I want Tools (and their Toolchains) to
stand alone easily, but also have some way to override their decisions at a
high level (globally, from cmd line, etc.)

And yes, with this system it is a goal that there would be no more "missing
Visual Studio" errors on Windows. :-)

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons tools refactoring progress

[Gary Oberbrunner]

I'm just starting to get back into it.
If you'd like to take a look at the current state of things, check out
h...@bitbucket.org/garyo/scons-newtool and look in
src/engine/SCons/ToolchainDesign.
The next thing on my list for it is a nice generalized executable-finder
(PATH, registry, env, hard-coded, etc.)
Any feedback much appreciated!

On Tue, Oct 13, 2015 at 6:09 PM, Bill Deegan 
wrote:

> Vasily,
>
> I think Gary was working on that. Work's ongoing.
> It's not imminent to be merged into main.
>
> Are you volunteering to help?
> ;)
>
> -Bill
>
> On Tue, Oct 13, 2015 at 2:29 PM, Vasily  wrote:
>
>> Hi all!
>>
>> I recall there were some plans on refactoring how Tools work in SCons.
>> Are there any news on that?
>>
>> Thanks,
>> Vasily
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Proper way to get File path (undocumented rfile)

[Gary Oberbrunner]

str(File) just calls f.path. There are also plenty of other attributes like
fullpath. Sometimes f.srcnode().path is useful. Most are documented, see
File and Directory Nodes in the man page. The ones that aren't (like rfile)
are intended for internal use but may occasionally still be useful.  See
the API docs at
http://www.scons.org/doc/latest/HTML/scons-api/SCons.Node.FS.File-class.html
for gory details.

-- Gary

On Fri, Oct 2, 2015 at 10:07 AM, Jonathon Reinhart <
jonathon.reinh...@gmail.com> wrote:

> I, too have come across scenarios where rfile() was the only way to
> accomplish exactly what I needed. I believe the scenario was this:
>
> The arguments / command-line parameters to my external utility were so
> complex, SCons couldn't handle it himself. So I wrote my own
> variable-function-thing (like ${_concat}) in which I needed to expand the
> Nodes to their paths, just like SCons would when expanding $TARGETS to
> their paths. This is how I ended up finding rfile().
>
> It seems like it should be documented.
>
>
>
>
>
> On Fri, Oct 2, 2015 at 4:15 AM, anatoly techtonik 
> wrote:
>
>> Hi,
>>
>> Currently the way to get filename from File node is to str() that File.
>> That's quite shady API, especially if used in function like:
>>
>> def convert(node):
>> return str(node).replace('\\', '/')
>>
>> I mean you have no idea what types of node are expected and why
>> there is slash escaping. The str(node) can return anything and
>> works on any types of nodes.
>>
>> So, there is undocumented method File.rfile() with the path.
>>
>> http://www.scons.org/doc/HTML/scons-api/SCons.Node.FS.File-class.html#rfile
>> Which contains os specific path and it is used for example in
>> https://github.com/wesnoth/wesnoth/pull/481/files
>>
>> The questions.
>> 1. Why it is called rfile?
>> 2. Should it be documented?
>> 3. What should be the proper API to get path info for File node?
>> 4. What is the proper API to convert paths to system-specific and to
>> canonical (forward slash) form?
>> --
>> anatoly t.
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
>
> --
> Computers are incredibly fast, accurate and stupid. Human beings are
> incredibly slow, inaccurate and brilliant. Together they are powerful
> beyond imagination.
> A. Einstein
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Roundup tracker demo instance...

[Gary Oberbrunner]

got it.

On Thu, Oct 1, 2015 at 2:17 AM, Florian Miedniak  wrote:

> Hm, I knew I forgot someone ;-) You should have got an invitation by now.
>
> -Florian
>
> 2015-10-01 4:14 GMT+02:00 Gary Oberbrunner :
>
>> I don't seem to have any access.  "Forgot password" doesn't work with any
>> username I tried...
>>
>> On Wed, Sep 30, 2015 at 4:58 PM, Florian Miedniak <
>> florian.miedn...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have created a on-demand trial setup of the JIRA + bitbucket
>>> integration here: https://scsandbox.atlassian.net with write access to
>>> both parts for Dirk, Gary, Bill Deegan and William Blevins. I'm sure
>>> there's someone I forgot ;-) Just tell me and I'll add you to the users
>>> list.
>>> The very basic integration works:
>>>   - Mention a JIRA issue (SCSAND-) in a commit message and push
>>> it to https://bitbucket.org/scsandbox/jira_bitbucket_integration -> The
>>> issue name will be a hyper-linked to JIRA
>>>  - If you open a JIRA issue on the right there is a section
>>> "Development" which shows all commits belonging to this issue. Here you can
>>> step-wise dive into the commit until you end up on bitbucket's commit view
>>> - It is possible (but not yet configured) to modify the standard JIRA
>>> issue workflow, so an issue e.g. transits to REVIEW to FIXED when a pull
>>> request gets merged. (And there is a ton of other event/notification
>>> configuration options available ...)
>>>
>>> The trial setup is available until 2015/10/6 (due to the trial license),
>>> so feel free to check its look and feel!
>>>
>>> -Florian
>>>
>>> 2015-09-29 8:52 GMT+02:00 Florian Miedniak :
>>>
>>>>
>>>>
>>>> 2015-09-28 21:42 GMT+02:00 William Blevins :
>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 28, 2015 at 7:45 PM, Russel Winder 
>>>>> wrote:
>>>>>
>>>>>> On Mon, 2015-09-28 at 13:56 +0100, William L Blevins wrote:
>>>>>> > […]
>>>>>> > I have used Jira and I think if we can get free instances for the
>>>>>> > project, then the direct jira -> bitbucket <- confluence setup will
>>>>>> > give us a lot of project management control.
>>>>>>
>>>>>> Personally I found Confluence a right royal pain in the arse. JIRA on
>>>>>> the other hand worked very well for me. The issue is whether SCons can
>>>>>> have a JIRA directly linked to the Mercurial repository and its pull
>>>>>> requests.
>>>>>>
>>>>>
>>>>>
>>>>> Since they are all Atlassian products, I cannot imagine "no" to be the
>>>>> answer; otherwise, what is the point?
>>>>>
>>>>>
>>>> William, I agree with you, that it is not the question, *if* there is
>>>> support for connecting bitbucket hosted mercurial repos with JIRA. (
>>>> http://blogs.atlassian.com/2012/07/connect-jira-to-your-git-or-mercurial-repositories-with-the-jira-dvcs-connector)
>>>> It's more the question how mature it is. From my previous experience,
>>>> Atlassian does a quite good job of integrating their products.
>>>> Nevertheless, the best (and IMO only) way to find out, if there are any
>>>> technical / user experiance obstacles left for using JIRA<->Bitbucket for
>>>> Scons, is to give it a try:
>>>> 1. Check for JIRA<->Mercurial on Bitbucket integration with a sandbox
>>>> project
>>>> 2. Adapt the scripts of Dirk to import the existing issues from tigris
>>>>
>>>> I'd volunteer to do this to have a solid basis for further
>>>> decision-making.
>>>>
>>>> -Florian
>>>>
>>>
>>>
>>> ___
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>>
>>
>>
>> --
>> Gary
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Roundup tracker demo instance...

[Gary Oberbrunner]

I don't seem to have any access.  "Forgot password" doesn't work with any
username I tried...

On Wed, Sep 30, 2015 at 4:58 PM, Florian Miedniak <
florian.miedn...@gmail.com> wrote:

> Hi,
>
> I have created a on-demand trial setup of the JIRA + bitbucket integration
> here: https://scsandbox.atlassian.net with write access to both parts for
> Dirk, Gary, Bill Deegan and William Blevins. I'm sure there's someone I
> forgot ;-) Just tell me and I'll add you to the users list.
> The very basic integration works:
>   - Mention a JIRA issue (SCSAND-) in a commit message and push it
> to https://bitbucket.org/scsandbox/jira_bitbucket_integration -> The
> issue name will be a hyper-linked to JIRA
>  - If you open a JIRA issue on the right there is a section "Development"
> which shows all commits belonging to this issue. Here you can step-wise
> dive into the commit until you end up on bitbucket's commit view
> - It is possible (but not yet configured) to modify the standard JIRA
> issue workflow, so an issue e.g. transits to REVIEW to FIXED when a pull
> request gets merged. (And there is a ton of other event/notification
> configuration options available ...)
>
> The trial setup is available until 2015/10/6 (due to the trial license),
> so feel free to check its look and feel!
>
> -Florian
>
> 2015-09-29 8:52 GMT+02:00 Florian Miedniak :
>
>>
>>
>> 2015-09-28 21:42 GMT+02:00 William Blevins :
>>
>>>
>>>
>>> On Mon, Sep 28, 2015 at 7:45 PM, Russel Winder 
>>> wrote:
>>>
 On Mon, 2015-09-28 at 13:56 +0100, William L Blevins wrote:
 > […]
 > I have used Jira and I think if we can get free instances for the
 > project, then the direct jira -> bitbucket <- confluence setup will
 > give us a lot of project management control.

 Personally I found Confluence a right royal pain in the arse. JIRA on
 the other hand worked very well for me. The issue is whether SCons can
 have a JIRA directly linked to the Mercurial repository and its pull
 requests.

>>>
>>>
>>> Since they are all Atlassian products, I cannot imagine "no" to be the
>>> answer; otherwise, what is the point?
>>>
>>>
>> William, I agree with you, that it is not the question, *if* there is
>> support for connecting bitbucket hosted mercurial repos with JIRA. (
>> http://blogs.atlassian.com/2012/07/connect-jira-to-your-git-or-mercurial-repositories-with-the-jira-dvcs-connector)
>> It's more the question how mature it is. From my previous experience,
>> Atlassian does a quite good job of integrating their products.
>> Nevertheless, the best (and IMO only) way to find out, if there are any
>> technical / user experiance obstacles left for using JIRA<->Bitbucket for
>> Scons, is to give it a try:
>> 1. Check for JIRA<->Mercurial on Bitbucket integration with a sandbox
>> project
>> 2. Adapt the scripts of Dirk to import the existing issues from tigris
>>
>> I'd volunteer to do this to have a solid basis for further
>> decision-making.
>>
>> -Florian
>>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Does SCons test support negative tests?

[Gary Oberbrunner]

On Tue, Sep 29, 2015 at 12:08 PM, Bill Deegan 
wrote:

> Gary,
>
> For this test I ended up just having the full expected output, in this
> case I effectively checked for the output not being there.
> It worked for the negative case because the output is pretty short.
>
> Can you use must_not_contain on stdout?
> I'm thinking our test framework docs are pretty sparse.
>

There's a _small_ amount in the wiki, at
https://bitbucket.org/scons/scons/wiki/DeveloperGuide/TestingMethodology/QMTestMethods
 and
https://bitbucket.org/scons/scons/wiki/DeveloperGuide/TestingMethodology.
The README in the QMTest dir is not all that helpful; that'd be a good
place for some of this IMHO.


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Does SCons test support negative tests?

[Gary Oberbrunner]

Can you just have two tests, one must_contain() and the other
must_not_contain()?

On Tue, Sep 29, 2015 at 11:47 AM, Bill Deegan 
wrote:

> Greetings,
>
> I'm looking through the test logic and I don't see a way to say:
> 1) Output must have xyz in it
> 2) AND must NOT have abc in it
>
> I'm working on a test for the append flag for Help() and depending on it's
> setting the output from
> scons -h
>
> should or shouldn't contain help from AddOption()'s.
>
> I could specify the exact full output expected, but it would seem easier
> to maintain if I only check for 1 and 2 above.
>
> Thanks,
> Bill
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Roundup tracker demo instance...

[Gary Oberbrunner]

On Thu, Sep 24, 2015 at 2:17 PM, William Blevins 
wrote:

> Functionality wise, what does round-up provide that tigris doesn't?


Lack of awfulness.  IMHO of course. :-)

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Atlassian, BitBucket, Mercurial

[Gary Oberbrunner]

Could be; pretty much _every_ project I can think of is using git now.  I
have to twist my brain around every time I work on SCons. :-)

On Wed, Sep 23, 2015 at 6:57 AM, Russel Winder  wrote:

> I see that Atlassian has further demoted the role of Mercurial at
> BitBucket, by expunging all reference to Mercurial on the BitBucket
> front page –  "BitBucket is the Git Solution…".
>
> Clearly Mercurial has no role at BitBucket as far as Atlassian is
> concerned. Git users will of course use GitHub, so is this the
> beginning of the end for BitBucket?
>
> --
> Russel.
>
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons 2.4.0 Released

[Gary Oberbrunner]

Next thing is to merge default into the python3 branch.  I did this a few
months ago; you can look at the merge to see the kinds of things that have
to be tweaked, it's not usually too bad.

On Tue, Sep 22, 2015 at 3:44 PM, Tim Jenness  wrote:

>
> > On Sep 22, 2015, at 12:33 , Bill Deegan 
> wrote:
> >
> > Tim,
> >
> > Feel free to help out on the python 3 work then.
> >
>
> Ok. Where do I start? (I’m trying to get a buildbot slave set up but the
> process of locating a linux machine is taking a while).
>
> Last time I looked the Python3 branch was a year old. Are we starting from
> current master? Are we committed to six or is future an option (I use
> future in my own projects).
>
> —
> Tim Jenness
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] sunar tool

[Gary Oberbrunner]

Looks like a bug to me.

On Sun, Sep 20, 2015 at 6:43 AM, Paweł Tomulik 
wrote:

> Hi,
>
> during my work on shared library versioning I found these lines in
> Tools/sunar.py (static library linker, in function generate()):
>
> env['SHLINK']  = '$LINK'
> env['SHLINKFLAGS'] = SCons.Util.CLVar('$LINKFLAGS -G')
> env['SHLINKCOM']   = '$SHLINK $SHLINKFLAGS -o $TARGET $SOURCES
> $_LIBDIRFLAGS $_LIBFLAGS'
>
>
> Does anyone know, why the static library linker (sunar) sets the flags
> of shared library builder? IMHO these should only be touched in
> sunlink.py (default linker on sunos). As for now, the shared library
> flags set in sunlink.py get overwritten by sunar.py which is quite
> confusing.
>
> Best Regards!
>
> --
> Pawel Tomulik
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Is there a way to search the wiki

[Gary Oberbrunner]

Greg hasn't participated in SCons development for some time now.

On Fri, Sep 18, 2015 at 1:13 PM, Jason Kenny  wrote:

> Is there a way to search the wiki. I try to find Greg noel page on iatap
> to review some ideas.
>
> Jason
>
> Btw does anyone know what has happened to Greg?
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Help debugging

[Gary Oberbrunner]

--debug=explain might help, Russel.

On Wed, Sep 16, 2015 at 6:48 AM, Russel Winder  wrote:

> Hi,
>
> I am getting some wrong, indeed inappropriate, behaviour with the D
> tool for shared library production. Clearly my problem :-)
>
> The question I have is: how do I find out why and action gets triggered
> when it shouldn't. I have a C++ and D build that are fundamentally the
> same, the C++ build behaves correctly, the D one does not. The -
> -tree=all are the same and appropriate, and yet the D tool is
> triggering an action when it shouldn't.
>
> Is there a know whay of tracking this behaviour?
>
> --
> Russel.
>
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] [Scons-users] SharedLibrary + SHLIBVERSION and cygwin

[Gary Oberbrunner]

I also didn't get any SCons time this weekend.  Let me see what I can do
soon.

On Mon, Sep 14, 2015 at 10:36 AM, Paweł Tomulik 
wrote:

> Thx,
>
> have a nice trip.
>
>
> W dniu 14.09.2015 o 16:02, William Blevins pisze:
> > Pawel,
> >
> > I'm travelling international atm, but I will try to look at it towards
> > the weekend.
> >
> > V/R,
> > William
> >
> > On Sep 14, 2015 8:10 AM, "Paweł Tomulik"  > <mailto:ptomu...@meil.pw.edu.pl>> wrote:
> >
> > How is it going?
> >
> >
> > W dniu 08.09.2015 o 23:55, Gary Oberbrunner pisze:
> > > Sorry I have been busy.  Will try to this weekend.  Anyone else?
> > >
> > > On Tue, Sep 8, 2015 at 5:41 PM, Paweł Tomulik
> > mailto:ptomu...@meil.pw.edu.pl>
> > > <mailto:ptomu...@meil.pw.edu.pl <mailto:ptomu...@meil.pw.edu.pl>>>
> > wrote:
> > >
> > > Hi,
> > >
> > >
> > > W dniu 01.09.2015 o 23:51, Paweł Tomulik pisze:
> > > > Hi,
> > > >
> > > > W dniu 30.08.2015 o 18:40, William Blevins pisze:
> > > >> Did you try the patch as a short term solution?
> > > >>
> > > >
> > > > I would rather propose a germ of long-term solution:
> > > >
> > > >
> >
> https://bitbucket.org/scons/scons/pull-requests/246/new-versioned-libraries-gnulink-and/diff
> > > >
> > > > The above PR reimplements the library versioning stuff.
> > Currently
> > > > gnulink and cyglink (tested).
> > > >
> > > > Best regards!
> > > >
> > >
> > >
> > > is someone attempting to look at this new PR?
> > >
> > >
> >
> https://bitbucket.org/scons/scons/pull-requests/247/new-versioned-libraries-gnulink-and/diff
> > >
> > >
> > > Regards!
> > > --
> > > Pawel Tomulik
> > > ___
> > > Scons-dev mailing list
> > > Scons-dev@scons.org <mailto:Scons-dev@scons.org>
> > <mailto:Scons-dev@scons.org <mailto:Scons-dev@scons.org>>
> > > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> > >
> > >
> > >
> > >
> > > --
> > > Gary
> > >
> > >
> > > ___
> > > Scons-dev mailing list
> > > Scons-dev@scons.org <mailto:Scons-dev@scons.org>
> > > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> > >
> >
> >
> > --
> > Paweł Tomulik, tel. (22) 234 7925
> > Instytut Techniki Lotniczej i Mechaniki Stosowanej
> > Politechnika Warszawska
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org <mailto:Scons-dev@scons.org>
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
> >
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
>
>
> --
> Paweł Tomulik, tel. (22) 234 7925
> Instytut Techniki Lotniczej i Mechaniki Stosowanej
> Politechnika Warszawska
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] [Scons-users] SharedLibrary + SHLIBVERSION and cygwin

[Gary Oberbrunner]

Sorry I have been busy.  Will try to this weekend.  Anyone else?

On Tue, Sep 8, 2015 at 5:41 PM, Paweł Tomulik 
wrote:

> Hi,
>
>
> W dniu 01.09.2015 o 23:51, Paweł Tomulik pisze:
> > Hi,
> >
> > W dniu 30.08.2015 o 18:40, William Blevins pisze:
> >> Did you try the patch as a short term solution?
> >>
> >
> > I would rather propose a germ of long-term solution:
> >
> >
> https://bitbucket.org/scons/scons/pull-requests/246/new-versioned-libraries-gnulink-and/diff
> >
> > The above PR reimplements the library versioning stuff. Currently
> > gnulink and cyglink (tested).
> >
> > Best regards!
> >
>
>
> is someone attempting to look at this new PR?
>
>
> https://bitbucket.org/scons/scons/pull-requests/247/new-versioned-libraries-gnulink-and/diff
>
>
> Regards!
> --
> Pawel Tomulik
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons Node ID

[Gary Oberbrunner]

On Fri, Sep 4, 2015 at 4:24 AM, anatoly techtonik 
wrote:

> On Fri, Sep 4, 2015 at 10:10 AM, Dirk Bächle  wrote:
>
>> On 04.09.2015 06:16, anatoly techtonik wrote:
>>
>>> I have another question about SCons. If I specify target explicitly, it
>>> ends up
>>> as str in BUILD_TARGETS and it is impossible to traverse. How do I
>>> transform it to Node if I don't know the type? I.e. how to lookup Node
>>> object
>>> by name?
>>>
>>>
>> you mean you explicitly specify a target "x" on the command line, but you
>> don't know whether it's a File or a Dir?
>> Can you come up with a short user scenario for this? What is it that
>> you're trying to accomplish?
>>
>
> The short user scenario - a person want to build wesnoth and executes
> `scons`. The output says that possible targets are "wesnoth" and
> "wesnothd". Because I don't have dependencies for "wesnoth", I specify
> "wesnothd" which ends up as str in BUILD_TARGETS and I can not traverse it.
>

Normally you just say e = Entry(str), which converts the string to an
Entry, which is a Node whose type is unknown.  At various points Entry
nodes are converted to their correct type once it can be deduced

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Mini announcement: v2.4 is near...

[Gary Oberbrunner]

My guess is this has something to do with the rpm packaging builder
(Tool/packaging/rpm.py).  It's probably getting a list of files or nodes,
and not sorting them.  os.listdir(), for instance, "returns path elements
in an arbitrary order".  Maybe something in that builder just needs to sort
them before use.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons webpage...

[Gary Oberbrunner]

On Fri, Aug 7, 2015 at 11:41 AM, Bill Deegan 
wrote:

> (Know anyone who wants to buy a 1953 MG TD.. I've got one left..


I don't, but the pic on FB looks gorgeous!  Who wouldn't want that?


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons webpage...

[Gary Oberbrunner]

The top menu obscures the top of each page, I guess that's what you mean by
the over-wide top menu.  With that fixed, it looks like it would be able to
functionally replace the current version.  A bit of styling and color might
be nice, with the brick logo etc.?  But otherwise I think it's promising.
It looks good on mobile too (other than again the top menu obscuring the
text), with a hamburger menu to select the different pages.  Responsive
design and all that modernity.

On Fri, Aug 7, 2015 at 10:50 AM, Bill Deegan 
wrote:

> Dirk,
>
> I'd say keep the docs separate.
> The pelican stylesheets are actually bootstrap stylesheets.
>
> Where/how should we solicit feedback?
>
> -Bill
>
> On Fri, Aug 7, 2015 at 7:15 AM, Dirk Baechle  wrote:
>
>> I guess we should collect some feedback first: What do other people/devs
>> say about the ¨new¨ SCons webpage? Is this a good direction to go, assuming
>> that we adapt some basic style things like the colours of headings, for
>> example?
>>
>> Remember, background of the whole ¨Pelican¨ endeavour was to be able to
>> offer Atom/RSS feeds to users.
>>
>> We should also test how the HTML docs display under the Pelican
>> stylesheets, or would these stay separate?
>>
>> Dirk
>>
>>
>> Am 7. August 2015 16:01:31 MESZ, schrieb Bill Deegan <
>> b...@baddogconsulting.com>:
>>>
>>> Dirk,
>>>
>>> Not a whole lot.
>>> I need to figure out how to better handle the over-wide top menu.
>>> And sounds like shufffle the home page and news page.
>>> Update for the latest couple releases.
>>>
>>> I might be able to knock that out today.
>>>
>>> -Bill
>>>
>>> On Fri, Aug 7, 2015 at 6:50 AM, Dirk Baechle  wrote:
>>>
 Bill,

 Yes, the ¨Pelican¨ project. ;) Sorry, but I completely forgot about
 that.
 Can you give a short status? What would be needed to get this live as
 our new webpage?

 Regards,

 Dirk

 Am 7. August 2015 15:36:34 MESZ, schrieb Bill Deegan <
 b...@baddogconsulting.com>:
 >Doh..
 >
 >Forgot the URL
 >http://scons.org/new/
 >
 >-Bill
 >

 --
 Sent from my Android with K-9 Mail.
 ___
 Scons-dev mailing list
 Scons-dev@scons.org
 https://pairlist2.pair.net/mailman/listinfo/scons-dev

>>>
>>>
>> --
>> Sent from my Android with K-9 Mail.
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons webpage...

[Gary Oberbrunner]

I removed some of the old ones for now. Restyling is a bit more than I have
the chops for right now, but I'm open to ideas like your suggestion.

On Fri, Aug 7, 2015 at 7:24 AM, Dirk Baechle  wrote:

> Hi Gary,
>
> I think we should try to get rid of the News section at the top of the
> main page in general. There will always be the danger of the news items
> pushing down the rest...if we leave it at its current place.
>
> Maybe we can use the left margin (similar to the right menu) to display
> the latest three News items in a somewhat smaller font? Just as an idea...
>
> Dirk
>
> Am 7. August 2015 11:42:07 MESZ, schrieb Gary Oberbrunner <
> ga...@oberbrunner.com>:
> >Are you just talking about the fact that there are too many releases
> >listed
> >under "Latest News" before you get to "What is SCons" and the quotes
> >etc.?
> >I can fix that.
> >
> --
> Sent from my Android with K-9 Mail.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons webpage...

[Gary Oberbrunner]

Are you just talking about the fact that there are too many releases listed
under "Latest News" before you get to "What is SCons" and the quotes etc.?
I can fix that.

On Fri, Aug 7, 2015 at 3:11 AM, Dirk Bächle  wrote:

> Hi there,
>
> I just noticed, that when I open the scons.org webpage in my browser it
> looks like the attached screenshot.
> Now imagine that you're someone who's interested in the project and opens
> the page the first time...it's bad UX because you don't see the vital info
> about the project itself.
>
> Can we do something about this? Now? ;)
>
> Second topic for today is, that I received a notification from
> printfection.com (where we have our SCons goodies store). They're going
> out of business, so the question from me to you is "Should I bother to look
> for a replacement, or do we simply take the Shop out?". Additional info:
> two hands are enough to show the amount of "sold items so far". ;)
>
> Best regards,
>
> Dirk
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] 2.3.6 out. Next up merging slots branch to default for stabilization and then release

[Gary Oberbrunner]

Congratulations all!  Looks great!

On Sat, Aug 1, 2015 at 12:06 AM, William Blevins 
wrote:

> Good news indeed!  Thanks for the release :)
>
> On Fri, Jul 31, 2015 at 11:35 PM, Bill Deegan 
> wrote:
>
>> Greetings,
>>
>> Now that 2.3.6 is out the door. Next step is to merge slots to default
>> and bump the version string to 2.4.0.
>>
>> We'll do some stabilization and then push out a release.
>> Hopefully without too much delay!
>>
>> Dirk - Please do the merge! Ready to let the world enjoy the benefits of
>> all your hard work! (and I assume many other contributed along the way)
>>
>> -Bill
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Problem using doc toolchain?

[Gary Oberbrunner]

All those look OK to me, Bill -- hmm, good thing I don't use swear words in
my scons source dir names!  I wasn't expecting to see those in the doc! :-)
There's no tool to check; you have to review by hand.  Usually the diffs
are short like this.

On Fri, Jul 31, 2015 at 1:30 PM, Bill Deegan 
wrote:

> Did a clean python, libxml2-2.9.2, libxslt-1.28 from source (ran into an
> issue with libpython.so from system python causing core dump with got me
> stuck for a while because the error you get until you dig into it just
> indicates that expat was not built with your python.. blog posting to
> follow on that fun).
>
> Once I sorted expat issue, and run
> /home/bdbaddog/tools/python-2.7.10/bin/python bin/docs-update-generated.py
> /home/bdbaddog/tools/python-2.7.10/bin/python bin/docs-validate.py
> /home/bdbaddog/tools/python-2.7.10/bin/python
> bin/docs-create-example-outputs.py
>
> I get only the following diffs:
> M doc/generated/examples/caching_ex-random_1.xml
>http://pastebin.com/UwE75eTY
> M doc/generated/examples/troubleshoot_explain1_3.xml
>   http://pastebin.com/3n2f3e4y
> M doc/generated/variables.gen
>   http://pastebin.com/UnhexDVR
> M doc/generated/variables.mod
>http://pastebin.com/E1nXYupB
>
> Are these all valid?
> Is there an easy way to check them (aka a tool?)
>
> -Bill
>
>
> On Fri, Jul 31, 2015 at 6:11 AM, William Blevins 
> wrote:
>
>> Dirk,
>>
>> I had lxslt installed but not python-lxslt.  Once that was installed it
>> was obvious that it switched from lxml to lxml2 usage.  I still got another
>> error.
>> On Jul 31, 2015 3:18 AM, "Dirk Bächle"  wrote:
>>
>>> Bill,
>>>
>>> On 30.07.2015 17:36, Bill Deegan wrote:
>>>
  From the code I've looked at if you have libxml2 & libxslt that is
 preferred, and then if not it will use lxml.


>>> your assumption is correct, this is done because libxml2 is faster in
>>> general.
>>>
>>> It seems that libxml2 and pure lxml have different behaviour regarding
>>> "normalizing namespaces" and that's where the diff comes from. This makes
>>> at least the validation in the SernaFree XML editor choke for the lxml
>>> output...:(
>>>
>>> I'm investigating this a little further and will try to find a way
>>> around this. I'd really like to have the (almost) same output for both XML
>>> toolchains, such that it gets accepted by most XML editors out there.
>>>
>>> @William: You said that after installing an additional package the
>>> processing got faster and correct? My guess would be that you now have a
>>> lxml distro/package that relies on libxml2 under the hood. This makes the
>>> error go away of course...
>>>
>>>
>>> I'll keep you posted, best regards,
>>>
>>> Dirk
>>>
>>> ___
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Cross-language support

[Gary Oberbrunner]

Yes, that's how we've done it in the past.  Sounds like doing it at the
same time as slots would be perfect.

-- Gary

On Tue, Jul 28, 2015 at 2:01 PM, Bill Deegan 
wrote:

> Gary,
>
> For such a change we should bump the second digit?
> 2.4?
>
> I agree we should not turn down a change because it will cause rebuilds
> where the past didn't as long as it is now more correct (which it should be
> with this change).
> Also agree we should be verbose in our notification of the impacts of the
> new change to avoid (as much as we can) "surprises".
>
>
> -Bill
>
>
> On Tue, Jul 28, 2015 at 9:57 AM, Gary Oberbrunner 
> wrote:
>
>> Hi Bill!  I don't think it's "compatibility breaking" in that existing
>> SConscripts will continue to work without change, but it _will_ require
>> (cause) a rebuild in many cases, and we do usually pre-announce those
>> changes and call them out in the release notes so people with huge projects
>> don't get surprised.  (Just to be clear, I'm not as averse to changes that
>> cause rebuilds as Steven used to be -- it's sensible to avoid them when
>> possible, but I don't think we need to avoid otherwise-sensible changes to
>> avoid rebuilds every now & then.)
>>
>> -- Gary
>>
>>
>> --
>>
>> *From: *"Bill Deegan" 
>> *To: *"SCons developer list" 
>> *Sent: *Tuesday, July 28, 2015 11:56:00 AM
>> *Subject: *Re: [Scons-dev] Cross-language support
>>
>> Gary & Dirk,
>>
>> Thoughts on whether this change introduces compatibility breaking change?
>>
>> -Bill
>>
>> On Tue, Jul 28, 2015 at 7:24 AM, Bill Deegan 
>> wrote:
>>
>>> William,
>>>
>>> It seems likely that since the change to scanning behavior will likely
>>> change many builds (as it's more accurate in tracing dependencies).
>>>
>>> As such I think we should pre-announce it.
>>>
>>> Is it safe to say this change "breaks compatibility"?
>>> (If you ran a build to completion without change, and reran it you'd get
>>> a new build, switch to this change and it may rebuild some files)
>>>
>>> -Bill
>>>
>>>
>>> On Tue, Jul 28, 2015 at 12:16 AM, William Blevins >> > wrote:
>>>
>>>> Once we have finalized the patch, so that the behavioral changes can be
>>>> concretely defined, I will update those two files or should we do a
>>>> pre-release announcement like with the slots changes?
>>>>
>>>> V/R,
>>>> William
>>>>
>>>> On Mon, Jul 27, 2015 at 8:34 PM, Bill Deegan >>> > wrote:
>>>>
>>>>> William,
>>>>>
>>>>> I just got around to doing a thorough read of your pull request and
>>>>> added a couple comments.
>>>>>
>>>>> Notably c++ doe (in the standard) support and require usage of header
>>>>> files with no extension:
>>>>> http://en.cppreference.com/w/cpp/header
>>>>>
>>>>> Another item is that since this is a change in functionality,
>>>>> documentation will need updates.
>>>>> And we should probably put a section in the src/CHANGES.txt and
>>>>> src/RELEASE.txt
>>>>>
>>>>> -Bill
>>>>>
>>>>> On Thu, Jul 9, 2015 at 7:18 AM, William Blevins >>>> > wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 9, 2015 at 5:56 AM, Russel Winder 
>>>>>> wrote:
>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> On Thu, 2015-07-09 at 00:20 -0400, William Blevins wrote:
>>>>>>> > Thanks for responding everyone.  I just wanted a "heart beat" so to
>>>>>>> > speak,
>>>>>>>
>>>>>>> You could always play the start of Dark Side of the Moon ;-)
>>>>>>>
>>>>>>> > since I wasn't sure how many members were watching the devs list.
>>>>>>> >  I'm not
>>>>>>> > asking anyone to stop what they are doing, but a lot of what I have
>>>>>>> > left is
>>>>>>> > requirements related questions.
>>>>>>>
>>>>>>> Whilst I note every email, I mostly delete and move o

Re: [Scons-dev] Cross-language support

[Gary Oberbrunner]

Hi Bill! I don't think it's "compatibility breaking" in that existing 
SConscripts will continue to work without change, but it _will_ require (cause) 
a rebuild in many cases, and we do usually pre-announce those changes and call 
them out in the release notes so people with huge projects don't get surprised. 
(Just to be clear, I'm not as averse to changes that cause rebuilds as Steven 
used to be -- it's sensible to avoid them when possible, but I don't think we 
need to avoid otherwise-sensible changes to avoid rebuilds every now & then.) 

-- Gary 

> From: "Bill Deegan" 
> To: "SCons developer list" 
> Sent: Tuesday, July 28, 2015 11:56:00 AM
> Subject: Re: [Scons-dev] Cross-language support

> Gary & Dirk,

> Thoughts on whether this change introduces compatibility breaking change?

> -Bill

> On Tue, Jul 28, 2015 at 7:24 AM, Bill Deegan < b...@baddogconsulting.com >
> wrote:

>> William,

>> It seems likely that since the change to scanning behavior will likely change
>> many builds (as it's more accurate in tracing dependencies).

>> As such I think we should pre-announce it.

>> Is it safe to say this change "breaks compatibility"?
>> (If you ran a build to completion without change, and reran it you'd get a 
>> new
>> build, switch to this change and it may rebuild some files)

>> -Bill

>> On Tue, Jul 28, 2015 at 12:16 AM, William Blevins < wblevins...@gmail.com >
>> wrote:

>>> Once we have finalized the patch, so that the behavioral changes can be
>>> concretely defined, I will update those two files or should we do a 
>>> pre-release
>>> announcement like with the slots changes?

>>> V/R,
>>> William

>>> On Mon, Jul 27, 2015 at 8:34 PM, Bill Deegan < b...@baddogconsulting.com >
>>> wrote:

 William,

 I just got around to doing a thorough read of your pull request and added a
 couple comments.

 Notably c++ doe (in the standard) support and require usage of header 
 files with
 no extension:
 http://en.cppreference.com/w/cpp/header

 Another item is that since this is a change in functionality, 
 documentation will
 need updates.
 And we should probably put a section in the src/CHANGES.txt and 
 src/RELEASE.txt

 -Bill

 On Thu, Jul 9, 2015 at 7:18 AM, William Blevins < wblevins...@gmail.com > 
 wrote:

> On Thu, Jul 9, 2015 at 5:56 AM, Russel Winder < rus...@winder.org.uk > 
> wrote:

>> 

>> On Thu, 2015-07-09 at 00:20 -0400, William Blevins wrote:
>> > Thanks for responding everyone. I just wanted a "heart beat" so to
>> > speak,

>> You could always play the start of Dark Side of the Moon ;-)

>> > since I wasn't sure how many members were watching the devs list.
>> > I'm not
>> > asking anyone to stop what they are doing, but a lot of what I have
>> > left is
>> > requirements related questions.

>> Whilst I note every email, I mostly delete and move on due to not
>> having enough time to properly contribute.

>> > I will hopefully still be able to work on SCons after early
>> > September, but
>> > I am going to be a little disorganized during the move and culture
>> > adjustment. I will be overseas for a year getting my MSc in Great
>> > Britain.

>> Just to note that Great Britain is a geographic but not political
>> entity, something the ISO committees handing out country codes chose to
>> forget when trying to solve the UK/Ukraine problem.

>> Where will you be studying and living when here?

> University of Sussex in Brighton; approximately Sept 2015 - Sept 2016.

>> > Also, I may not have my high-end workstation. I'm still debating
>> > whether or
>> > not I want to break it down and ship it.

>> I guess this depends on cost. It always seems that countries shipping
>> to UK pay about 0.5 or 0.3 the cost of shipping the same from the UK.
>> Basically all companies (especially USA ones) charge far more in the UK
>> for everything than they charge anywhere else in the world.

> Cost plus risk of it getting damaged. I generally build my own 
> workstations, so
> it's not like shipping X-U server form-factored machines. I will have to
> dismantle it prior to shipping. I'm tempted to ship it case less and buy
> another one in Britain because it'll be cheaper than shipping (probably).

>> --
>> Russel.
>> =
>> Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
>> 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
>> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev

> ___
> Scons-dev mailing list
> Scons-dev@scons.or

Re: [Scons-dev] Cross-language support

[Gary Oberbrunner]

I'm here too -- more or less.  Having worked a little bit with you on the
original version of this, I'd very much like to see it get in.  Your #2 is
fine I think.  #1 is complicated.  #3 I don't remember the details, will
have to review again.

On Wed, Jul 8, 2015 at 7:59 PM, Bill Deegan 
wrote:

> William,
>
> Nothing that you've written to this email can be properly responded to
> with a brief look a the code or issues involved.
> So first let me say thank you for your persistence on working on this
> issue and looking deeper into SCons than most.
>
> For myself I've been training for a half IronMan which has eaten up the
> bulk of my alotted open source participation time.
> Luckily that event is Sunday and so next week (assuming I survive ;) I'll
> have time to do a deep dig and give thoughtful comments.
>
> -Bill
>
>
> On Wed, Jul 8, 2015 at 7:23 PM, William Blevins 
> wrote:
>
>> Yeah.  The last few times I used the Dev list no one responded, so I just
>> wanted to make sure someone was out there somewhere :)
>>
>> On Wed, Jul 8, 2015 at 7:09 PM, Jason Kenny  wrote:
>>
>>>   I have.. I plan to respond soon [image: Smile]
>>>
>>> Jason
>>>
>>>  *From:* William Blevins 
>>> *Sent:* Wednesday, July 8, 2015 5:59 PM
>>> *To:* SCons developer list 
>>> *Subject:* Re: [Scons-dev] Cross-language support
>>>
>>>   Is there anyone on this mailing list?
>>>
>>> I just want to make sure someone *might* have even read this email.
>>>
>>> V/R,
>>> William
>>>
>>> On Mon, Jul 6, 2015 at 8:38 PM, William Blevins 
>>> wrote:
>>>
 Team,

 Due to some upcoming real life events, I would like to wrap up the
 cross-language scanner support materials by Sept 1, 2015.  I was working
 with Jason recently, but he got side-tracked with his own real life events.

 It is mostly complete.  There are really only 3 remaining items that I
 am aware (might be some other languages I cannot test). Details available
 in the patch discussion:
 https://bitbucket.org/scons/scons/pull-request/237/issue-2264-cross-language-scanner-support/diff

 TL;DR
 1. Recursive install scanning.  This one is somewhat involved, but
 could be easy if we decide to simply disable scanner recursion of the
 install builder.  Not sure if this is an option.
 2. Is the Ignore() for QT satisfactory?  I assume yes.
 3. Is enforcing valid keys satisfactory?  I can return the input if not
 which will be similar to past behavior.

 V/R,
 William

>>>
>>>
>>> --
>>> ___
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>>
>>> ___
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>>
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons release version tagging question

[Gary Oberbrunner]

Pretty sure yes.  All that is checked in on each release branch so you can
see it.

On Wed, Jun 17, 2015 at 8:40 PM, Bill Deegan 
wrote:

> Gary,
>
> Were you calling bootstrap.py REVISION=2.3.4 then?
>
> -Bill
>
> On Wed, Jun 17, 2015 at 4:56 PM, Gary Oberbrunner 
> wrote:
>
>> IMHO, version number alone is fine.  Probably the usual process which has
>> the release on its own branch is why this normally works.  But it is
>> time-consuming so if you want to simplify I'm all for it.
>>
>> On Wed, Jun 17, 2015 at 7:40 PM, Bill Deegan 
>> wrote:
>>
>>> Greetings,
>>>
>>> I'm fixing some logic in SCons's own SConstruct which sets the revision
>>> number.
>>> Currently is has the revision #, changeset has, branch, and whether it's
>>> modified.
>>>
>>> I also notice that 2.3.4 didn't have this info, so I'm guessing it
>>> bootstrap.py was passed the revision id
>>>
>>> (venv)WilliamsMacBook:scons-2.3.4 bdbaddog$ scons --version
>>> SCons by Steven Knight et al.:
>>> script: v2.3.4, 2014/09/27 12:51:43, by garyo on lubuntu
>>> engine: v2.3.4, 2014/09/27 12:51:43, by garyo on lubuntu
>>> engine path: ['/Users/bdbaddog/tmp/venv/lib/scons-2.3.4/SCons']
>>> Copyright (c) 2001 - 2014 The SCons Foundation
>>>
>>> Should this be the practice going forward?
>>> Or is there value in having 2.3.5, revision #3252, changeset 385adb84f
>>> for example?
>>>
>>> -Bill
>>>
>>> ___
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>>
>>
>>
>> --
>> Gary
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons release version tagging question

[Gary Oberbrunner]

IMHO, version number alone is fine.  Probably the usual process which has
the release on its own branch is why this normally works.  But it is
time-consuming so if you want to simplify I'm all for it.

On Wed, Jun 17, 2015 at 7:40 PM, Bill Deegan 
wrote:

> Greetings,
>
> I'm fixing some logic in SCons's own SConstruct which sets the revision
> number.
> Currently is has the revision #, changeset has, branch, and whether it's
> modified.
>
> I also notice that 2.3.4 didn't have this info, so I'm guessing it
> bootstrap.py was passed the revision id
>
> (venv)WilliamsMacBook:scons-2.3.4 bdbaddog$ scons --version
> SCons by Steven Knight et al.:
> script: v2.3.4, 2014/09/27 12:51:43, by garyo on lubuntu
> engine: v2.3.4, 2014/09/27 12:51:43, by garyo on lubuntu
> engine path: ['/Users/bdbaddog/tmp/venv/lib/scons-2.3.4/SCons']
> Copyright (c) 2001 - 2014 The SCons Foundation
>
> Should this be the practice going forward?
> Or is there value in having 2.3.5, revision #3252, changeset 385adb84f
> for example?
>
> -Bill
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Wiki down again

[Gary Oberbrunner]

I don't have the time/energy/desire to continue working on a system that is
unsustainable for us, and seems to be getting more so.  If you'd like to
push on it, feel free.

-- Gary

On Thu, Jun 4, 2015 at 8:25 AM, anatoly techtonik 
wrote:

> Can they be more accurate where exactly the vulnerability is? IIRC we
> have 1.9.8 version (latest) installed, so if there is an exploit, the
> upstream should be notified too.
>
> On Thu, Jun 4, 2015 at 1:05 PM, Gary Oberbrunner 
> wrote:
> > Pair said it was an exploited attack on the wiki script itself this time,
> > which is worse.  Usually it's "just" excessive load due to spammers
> trying
> > to create pages, which is basically a DoS.
> >
> > On Thu, Jun 4, 2015 at 3:13 AM, anatoly techtonik 
> > wrote:
> >>
> >> On Wed, Jun 3, 2015 at 7:56 PM, William Blevins 
> >> wrote:
> >> > Wiki is down again due to invalid permissions.  I assume more DOS
> >> > attacks.
> >> > We should consider changing providers or something...
> >>
> >> First, let's have some proof that it is DOS attack. Do you have access
> >> to logs and
> >> statistics?
> >>
> >> --
> >> anatoly t.
> >> ___
> >> Scons-dev mailing list
> >> Scons-dev@scons.org
> >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
> >
> >
> >
> > --
> > Gary
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
>
>
>
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Wiki down again

[Gary Oberbrunner]

Pair said it was an exploited attack on the wiki script itself this time,
which is worse.  Usually it's "just" excessive load due to spammers trying
to create pages, which is basically a DoS.

On Thu, Jun 4, 2015 at 3:13 AM, anatoly techtonik 
wrote:

> On Wed, Jun 3, 2015 at 7:56 PM, William Blevins 
> wrote:
> > Wiki is down again due to invalid permissions.  I assume more DOS
> attacks.
> > We should consider changing providers or something...
>
> First, let's have some proof that it is DOS attack. Do you have access
> to logs and
> statistics?
>
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Wiki down again

[Gary Oberbrunner]

Yes.  Grr.  This one is even worse, apparently there's an exploited
vulnerability in the wiki script. :-(

We have all the moin content; if anyone can help translate it to _anything_
so we can get it live on an AWS instance or whatever (just a git-backed
wiki or anything) that would be very helpful.

On Wed, Jun 3, 2015 at 12:56 PM, William Blevins 
wrote:

> Wiki is down again due to invalid permissions.  I assume more DOS
> attacks.  We should consider changing providers or something...
>
> V/R,
> William
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] How to traverse the graph after files are read

[Gary Oberbrunner]

On Wed, Jun 3, 2015 at 6:54 AM, anatoly techtonik 
wrote:

> But I have plenty of other files in current directory. Why those are
> not included?
>
> At the end of reading the SConstruct, i.e. before the build phase begins,
SCons only creates Nodes for files it has been told about.  I think if you
were to try this at the end of the build phase  (register a function with
python atexit.register for instance) I think the other files would be
there.  Though they might be only if "." is used as a source, I'm not sure.


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] How to traverse the graph after files are read

[Gary Oberbrunner]

Because it is a child of "." (the top dir) -- Dir nodes have all their
existing and to-be-generated files as children.

On Wed, Jun 3, 2015 at 2:10 AM, anatoly techtonik 
wrote:

> Interesting stuff. If I create an empty SConstruct:
>
> Entry("xxx")
>
> Then `scons --tree=all` gives a tree with SConstruct
> name included into the build graph:
>
> scons: `.' is up to date.
> +-.
>   +-SConstruct
>   +-xxx
>
> I can understand that xxx is at the root, but why
> SConstruct is also included?
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Merge PR #235 before release

[Gary Oberbrunner]

If you're interested in this problem, I suggest reading
https://docs.python.org/2/howto/unicode.html which has all the details
(including how to ignore decode errors), and of course check out the
python3 branch of scons where a lot of unicode handling has been done (but
much is still left to do iirc).  I don't think pretending strings are in
the cp437 encoding is a particularly good plan. ISO 8859-1 or Windows
CP1252 would probably give better results in some cases but you still need
to ignore errors in the decode.  And of course if the string actually is
utf-8 with non-ascii chars, either of these encodings will return a string
of the wrong length, not just wrong characters; and re-encoding it for
output or storage will completely mangle it.

Of course we _can_ know the encoding of the filenames in the filesystem,
that's what sys.getfilesystemencoding() is for (see the unicode link
above). Reading file contents and handling stdout/stderr from SCons
subprocesses is much more of a challenge.


On Thu, May 28, 2015 at 3:28 AM, anatoly techtonik 
wrote:

> I found a way to convert any binary string to Unicode without crashing -
> http://stackoverflow.com/a/27527728/239247 That would correctly
> convert all `ascii` characters (and will probably make it possible to use
> ANSI graphics if unicode font supports that), but it will not work for
> other
> utf-8 characters.
>
> Python 3 adds some surrogateescape, but that is not present in Python 2.
>
> http://stackoverflow.com/questions/19649463/how-to-do-surrogateescape-in-python2
> I don't know why they called it "surrogate" - it is a freaky word.
>
> On Wed, May 27, 2015 at 4:33 PM, Kenny, Jason L 
> wrote:
> > I would agree with this.
> >
> >
> >
> > In general the OS today store file data ( ie the file system data not the
> > data in the file) in Unicode ( be it utf-16 or utf-8). On Linux this is
> not
> > always the case it could be big5 or some other locale encoding.  On Linux
> > there are means to see what the “native” encoding is to use it.
> >
> >
> >
> > I should note that the idea of converting binary to Unicode does not
> really
> > exist. The point of a binary string to is to hold random data ( ie like a
> > double in the raw form 64-bit vs the dec values of 1.2385). One can
> assume
> > that it is a certain code page encoding and convert from that. And like I
> > stated above there are api to see what the locale code page encoding is
> and
> > that can be used to convert the code to the local ANSI/OEM encoding.
> This is
> > different from a binary string.
> >
> >
> >
> > Jason
> >
> >
> >
> >
> >
> >
> >
> > From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Gary
> > Oberbrunner
> > Sent: Wednesday, May 27, 2015 7:43 AM
> > To: SCons developer list
> > Subject: Re: [Scons-dev] Merge PR #235 before release
> >
> >
> >
> >
> >
> > On Wed, May 27, 2015 at 6:52 AM, anatoly techtonik 
> > wrote:
> >
> > What I need is a bulletproof way to convert from anything to unicode.
> This
> > requires some kind of escaping to go forward and back. Some helper
> > methods like u2b() (unicode to binary) and b2u(). I am quite surprised
> that
> > so far I found nothing for this "simple" case.
> >
> >
> > That's because in general the encoding of the "binary" string is unknown.
> > Is it ascii, utf-8, Windows CP-1252, shift-JIS, or something else?  You
> > can't decode such a string to Unicode without knowing the encoding.
> Check
> > out the python-3 branch where we've been working through some of those
> > issues.  Your u2b is "easy" if you assume you want the binary to be utf-8
> > encoded, which is normally safe; this conversion is guaranteed to work.
> > Your b2u is not so easy.  You can't just assume utf-8 as you might
> think; if
> > the string has invalid utf-8 bytes it'll raise an error or generate dummy
> > chars depending on the args you pass to str.decode().  At least it'll get
> > mangled if it's in a different encoding than you expect.
> >
> >
> >
> > --
> >
> > Gary
> >
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
>
>
>
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Merge PR #235 before release

[Gary Oberbrunner]

On Wed, May 27, 2015 at 6:52 AM, anatoly techtonik 
wrote:

> What I need is a bulletproof way to convert from anything to unicode. This
> requires some kind of escaping to go forward and back. Some helper
> methods like u2b() (unicode to binary) and b2u(). I am quite surprised that
> so far I found nothing for this "simple" case.
>

That's because in general the encoding of the "binary" string is unknown.
Is it ascii, utf-8, Windows CP-1252, shift-JIS, or something else?  You
can't decode such a string to Unicode without knowing the encoding.  Check
out the python-3 branch where we've been working through some of those
issues.  Your u2b is "easy" if you assume you want the binary to be utf-8
encoded, which is normally safe; this conversion is guaranteed to work.
Your b2u is not so easy.  You can't just assume utf-8 as you might think;
if the string has invalid utf-8 bytes it'll raise an error or generate
dummy chars depending on the args you pass to str.decode().  At least it'll
get mangled if it's in a different encoding than you expect.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Time for a release?

[Gary Oberbrunner]

Wiki's back up.

On Thu, May 21, 2015 at 3:16 AM, Dirk Bächle  wrote:

> On 21.05.2015 05:20, Bill Deegan wrote:
>
>> William,
>>
>> Of course your vote counts!
>> It's open source.
>>
>>
> +1 :)
>
> Dirk
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] How to traverse the graph after files are read

[Gary Oberbrunner]

On Wed, May 20, 2015 at 11:50 AM, Alexandre Feblot 
wrote:

> I did such kind of traversal once: http://pastebin.com/KyEg5ngS
> Maybe that was even based on something found in the wiki.


I'm not 100% certain, but I believe calling node.children()  can invoke
scanners and other things that should normally be done in particular orders
by the build process rather than during the SConstruct-reading phase.  Of
course it is likely to be more complete than node.sources.


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] How to traverse the graph after files are read

[Gary Oberbrunner]

On Wed, May 20, 2015 at 11:25 AM, anatoly techtonik 
wrote:

> I want to get target Node based on name passed from command line.
> How to do that?
>

node = File(name)

How to get list of all targets to be built?  User guide:
http://www.scons.org/doc/HTML/scons-user/ch10s03.html#idp3074280

the BUILD_TARGETS variable contains a list of the command-line targets, if
any were specified, and if no command-line targets were specified, it
contains a list of the targets specified via the Default method or function


Note that it contains a list of Nodes, so you don't need to do anything,
just iterate over it.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] How to traverse the graph after files are read

[Gary Oberbrunner]

On Wed, May 20, 2015 at 9:47 AM, anatoly techtonik 
wrote:

> If so, then that means that every target should
> be a filesystem object?
>
> What is target then? If it is a name, how a lookup if made to locate it in
> FS tree?
>

Every target (and source, and intermediate) is a Node.  The Node object
knows everything about that node, including name, path, parent, sources,
builder, build state, and so on.  There is no "lookup" in the sense you're
talking about.

If you want to get the Node object corresponding to a filename, just call
f=File("myfile") or f=File("/a/b/c/myfile") etc.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] How to traverse the graph after files are read

[Gary Oberbrunner]

On Wed, May 20, 2015 at 6:43 AM, anatoly techtonik 
wrote:

> The confusing part is that
> node graph is derived from filesystem.
>

FS represents the filesystem, both on disk and what will exist once all
targets are built.

I didn't say start from the filesystem, I said start from your target(s).

myprog=Program(...)
...
# at end of SConstruct:
visit_node_sources_recursively(myprog)

you just have to write visit_node_sources_recursively, following each
node's .sources list.  myprog is a File node (actually a list of those).
Nowhere should you need FS.


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Tutorial for Linux versioned libraries

[Gary Oberbrunner]

SCons Install just copies files (and in this case makes symlinks).
Building installers is a whole different thing.  SCons can do it, but
Install isn't what you're looking for.

On Tue, May 19, 2015 at 8:51 AM, anatoly techtonik 
wrote:

> On Tue, May 19, 2015 at 3:29 AM, William Blevins 
> wrote:
> >> Anatoly,
> >>
> >> > I've sent a pull request with the changes:
> >> > https://github.com/techtonik/RHVoice/pull/1
> >>
> >> Thanks. I need to understand the issue better before merging it.
> >> 1. If RHVoice needs those version numbers at all?
> >> 2. Why it tries to load so.0 when there is .0.0.0?
> >
> >
> > Here is my understanding of linux standards for shared libraries:
> >
> > Example:
> > thing.so -> thing.so.1
> > thing.so.1 -> thing.so.1.2.3
> > thing.so.1.2.3 (the real file)
> >
> > GNU linkers (and others) embed shared library information into the final
> > product in the form thing.so.1, so that the library can undergo patch
> > updates (EG. 1.2.3 -> 1.2.4) without requiring the application to be
> > recompiled.
>
> That make it clear. Thanks.
>
> The only question is the Install stuff. The operating system knows better
> where to install things, no? It creates a package registry and tracks all
> the
> files. Is SCons Install just a development hack?
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] How to traverse the graph after files are read

[Gary Oberbrunner]

At the end of your SConstruct, start with the target nodes and recurse into
each node.sources . This is incomplete of course if you have any source
generation or emitters etc. But it may be useful depending on what you're
doing.

-- 
Gary (sent from my Android)
On May 19, 2015 3:58 AM, "anatoly techtonik"  wrote:

> So far I discovered Taskmaster.
>
> Taskmaster
> This is the main engine for walking the dependency graph and
> calling things to decide what does or doesn't need to be built.
>
> But it looks like it already needs a graph of nodes to process and
> I don't see where to get them.
>
>
> On Tue, May 19, 2015 at 10:51 AM, anatoly techtonik 
> wrote:
> > No. I need a programmatic way to do this from Main.py
> > There is a fs object after SCons read all files, but I don't
> > understand how filesystem becomes a build graph.
> >
> >
> > On Tue, May 19, 2015 at 1:03 AM, William Blevins 
> wrote:
> >> --tree=all plus --dry-run should work?
> >>
> >> On May 18, 2015 2:11 PM, "anatoly techtonik" 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I am trying to get SCons build graph after files
> >>> are read, but before the processing is started.
> >>>
> >>> I want it to be an alternative to build process
> >>> and interactive mode:
> >>>
> >>>
> https://bitbucket.org/scons/scons/src/95b566e4baf0253e1b36b8a9e00a97cd84d22566/src/engine/SCons/Script/Main.py?at=default#cl-1091
> >>>
> >>> How to start traversing nodes without building?
> >>> --
> >>> anatoly t.
> >>> ___
> >>> Scons-dev mailing list
> >>> Scons-dev@scons.org
> >>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >>
> >>
> >> ___
> >> Scons-dev mailing list
> >> Scons-dev@scons.org
> >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >>
> >
> >
> >
> > --
> > anatoly t.
>
>
>
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons and Python 3.0

[Gary Oberbrunner]

On Wed, Feb 25, 2015 at 3:31 PM, Russel Winder  wrote:

> On Wed, 2015-02-25 at 21:10 +0100, Dirk Bächle wrote:
> […]
> >
> > you're aware of the fact that we already have a branch for this
> (python3-port)?
>
> It is though now seriously out of date, and not being worked on by
> people doing things, just talked about by people like me hoping things.
>
> It shouldn't be all that out of date.  I merged default branch into it
last year; there haven't been huge changes since then.  Doing another merge
into it to keep it current should not be a big task. The idea is that at
some point (not all that far from now) it should get finished (so the tests
pass) and merged back into the default branch, then we have a working
2.7/3.x codebase.

-- Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] mimetypes: adding mimetype for scons scripts

[Gary Oberbrunner]

On Wed, Jan 21, 2015 at 8:28 AM, Carnë Draug 
wrote:

>
> what if the magic uses the following globs for filenames "SConstruct",
> "SConscript", and "SConscript.*" ?


These seem good to me.  I think a few people may use *.scons, but that's
probably not popular enough to deserve going into shared-mime-info.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] mimetypes: adding mimetype for scons scripts

[Gary Oberbrunner]

On Wed, Jan 21, 2015 at 8:05 AM, Carnë Draug 
wrote:

> ...
> >>> scons [1] is a build system and I was thinking of adding it to
> >>> shared-mime-info.  Its files are very simple to identify, they are
> >>> always named SConstruct or SConscript.  These files are also valid
> >>> python scripts.
> >>>
> >>> Should shared-mime-info identify them (I can submit a git patch, no
> >>> problem)
>

This seems like an easy thing to add, with some possible upside and no
downside.  So why not, I say. Carnë, I think it would be better for you to
add it to shared-mime-info; SCons could do it but (a) it would be more
complex, and (b) it wouldn't identify SConstructs when SCons isn't
installed.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] scons-local .zip 2015

[Gary Oberbrunner]

On Sun, Jan 11, 2015 at 9:10 AM, anatoly techtonik 
wrote:

> > We are creating .zip package manually without distutils, which is a
> > good thing, because we have full control over what happens and don't
> > depend on distutils bug. I am working on a patch,
>
> I have the fix, but testing it requires fixing build process on Windows.
> This PR partly solves the problem. Probably on Dirk's part.
>
> https://bitbucket.org/scons/scons/pull-request/204/fix-build-on-windows-with-missing-doc/diff


I'm not sure I understand this.  Are you trying to build scons itself (the
release packages) on Windows?  I doubt that's ever been tried.  The
standard release process always runs on Linux, where it builds everything
including the Windows setup and zip packages.  I wouldn't want to make the
release engineer have to use two machines to produce a SCons release.  But
maybe that's not what you're doing here; please explain further.


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] PRs marked as declined

[Gary Oberbrunner]

On Sun, Jan 11, 2015 at 9:12 AM, anatoly techtonik 
wrote:

> On Sun, Jan 11, 2015 at 4:25 PM, Gary Oberbrunner 
> wrote:
> > Our usual problem is we merge a PR manually, but then bitbucket doesn't
> > recognize the change for whatever reason, and there's no way to "manually
> > accept" a PR (there's a bitbucket issue for this) so we have to decline
> it
> > and say it was really accepted.  I don't think we've seen truly
> spontaneous
> > declines.
>
> Do you mean that Merge button doesn't work after the manual merge?
>
> Correct -- when I tried it a long time ago it created an extra merge
commit and messed things up.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] PRs marked as declined

[Gary Oberbrunner]

Our usual problem is we merge a PR manually, but then bitbucket doesn't
recognize the change for whatever reason, and there's no way to "manually
accept" a PR (there's a bitbucket issue for this) so we have to decline it
and say it was really accepted.  I don't think we've seen truly spontaneous
declines.

On Sun, Jan 11, 2015 at 6:20 AM, anatoly techtonik 
wrote:

> Hi,
>
> I don't remember if it is the bug that we before, but the next time it
> happens, the best way would be to leave a note here:
>
> https://bitbucket.org/site/master/issue/9603/pull-request-declined-spontaneously-bb
>
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Parts checkout URL needs authorization

[Gary Oberbrunner]

This is still true.  Just wanted to download the latest Parts via svn but
as Anatoly says, it requires authentication.

-- Gary

On Fri, Dec 26, 2014 at 4:56 AM, anatoly techtonik 
wrote:

> Christmas!
>
> Jason, I thought you need to know that URL for parts requires
> authentication:
> On this page:
> http://parts.tigris.org/servlets/ProjectProcess?pageID=JlBX2F
> The URL:
> http://parts.tigris.org/svn/parts/tags/parts_0.10.8
>
> Seems like a major issue to me.
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Clang support

[Gary Oberbrunner]

On Mon, Jan 5, 2015 at 7:02 PM, Paweł Tomulik 
wrote:

> Looks like SCons is missing a "tool preference system", where each user
> (developer, not end user) could easily re-define by its own the preferred
> order of compiler toolchains. The same applies to other tools. Don't worry,
> there will always be room for discussion, for example "what should be the
> default preference order" :)


This will be (much) more configurable at some point.  There will be chains
of tools, selectable and overridable and auto-detectable in various ways.
I'm working on it.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Clang support

[Gary Oberbrunner]

On Mon, Jan 5, 2015 at 7:48 AM, Paweł Tomulik 
wrote:

>  ...
> I have a project where I just set construction variables CC=clang and
> CXX=clang++ and it works well
>

That's more or less what we do too (in addition to some clang-specific
flags we need).  Seems to work fine.

It'll be much easier to support clang with the new toolchain stuff I'm
working on (slowly, but r>0).

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] RELEASE.txt bug

[Gary Oberbrunner]

2014-12-23 8:39 GMT-05:00 anatoly techtonik :

> http://www.scons.org/RELEASE.txt
>
> """RELEASE 2.3.4 - Mon, 27 Sep 2014 12:50:35 -0400
>
>   Please consult the RELEASE.txt file for a summary of changes..."""
>
> ???
>

That sure looks like a bug. :-)

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Build server for Windows

[Gary Oberbrunner]

Nice!  Can we integrate that into our build process?

On Thu, Dec 18, 2014 at 6:33 AM, anatoly techtonik 
wrote:
>
> Hi,
>
> Found a Windows alternative to drone.io - check this out:
> https://ci.appveyor.com/project/anatolytechtonik/scons/build/2-default
>
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] What to replace the wiki with?

[Gary Oberbrunner]

On Sat, Dec 13, 2014 at 3:54 PM, Bill Deegan 
wrote:
>
> All,
>
> I think two items for wiki are must have:
> 1) full text searchable from the wiki
> 2) index able by google and others.
>
> I'm pretty sure neither bitbucket nor github has both. (Though I suppose 1
> would come with 2)
> As for giving specific contributors unfettered write access. I think we
> could just give them write access to a given repo. (which is where the wiki
> is).
> No such access control exists for a project's wiki under bitbucket.
>
> Assuming I have a host to put moin on, does anyone know how to configure
> it to minimize the load it causes? Can you put a caching proxy in front of
> it?
>

I'm not certain what has caused our load spikes at pair, but I think some
kind of rate-limiting of requests from a single IP would help a lot. I
don't think moin's page rendering is very expensive.  (Moin does some
caching anyway: http://moinmo.in/MoinCaching)

If you can re-host our wiki somewhere, that might be the best solution.  I
agree, neither of the current proposals really do it.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] What to replace the wiki with?

[Gary Oberbrunner]

On Sat, Dec 13, 2014 at 12:25 PM, Dirk Bächle  wrote:
>
> On 13.12.2014 17:53, Bill Deegan wrote:
>
>> Can find search on bitbucket version, but it's there on github.
>>
>>  Good point, that would speak for github then..since bitbucket isn't too
> interested in searching and hierarchies:
>
> https://groups.google.com/forum/#!topic/bitbucket-users/R0ZJrWhhMTo
> http://stackoverflow.com/questions/3050545/bitbucket-
> wiki-create-a-heirarchy-structure
>
> But even github doesn't do a full text search, it can only find page
> titles. :(


On the other hand, bitbucket seems OK with /-separated hierarchical pages,
where github doesn't seem to.  And we have many of those.

Some of the pages (e.g.
https://bitbucket.org/scons/scons/wiki/GSoC2012/Ideas) have been cut short
by the converter too. I'll keep poking at it.  You can still see the moin
pages at least in bitbucket;
https://bytebucket.org/scons/scons/wiki/GSoC2012/Ideas.moin

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] What to replace the wiki with?

[Gary Oberbrunner]

Here's a wiki progress report.

* I've re-enabled the regular wiki, in read-only mode.  That way at least
people can see it.  Pair may take it down again but it's better than
nothing.
* I put up test versions of the wiki, converted to markdown, on both
bitbucket and github.
  - bitbucket: https://bitbucket.org/scons/scons/wiki/FrontPage (this is
backed by an hg repo)
  - github: https://github.com/garyo/scons-wiki/wiki/FrontPage (this is
backed by a git repo)

IMHO, the bitbucket version looks better.  They both are functional.  They
both have online editors, and both allow specifying a list of approved
contributors who can edit directly, without making pull requests.  They are
both DVCS-backed and can accept pull requests (I think, haven't tried
that.)  I don't know much yet about searchability or TOCs.

Feel free to play with them (but don't expect your changes to persist
forever, these are just tests).  Please let me know what you find.

The conversion process to markdown was _definitely_ not perfect.  There are
many little errors and markup oddities that would need to be cleaned up by
hand.  Tables especially suffer, since Markdown's table support is minimal.
(there is no rowspan support for instance.)  There may be ways to fix the
conversion script and re-run the conversion as we find global conversion
issues.  The FrontPage looks particularly bad, but don't judge the
conversion process by that, since it has much more custom markup than most
of the regular pages.

-- Gary


On Sat, Dec 13, 2014 at 5:58 AM, anatoly techtonik 
wrote:
>
> On Sat, Dec 13, 2014 at 12:45 PM, Dirk Bächle  wrote:
> > Someone has to accept (and review?) all the incoming pull requests. And
> you
> > can't simply mark persons "trustworthy for the future", as with the
> > ApprovalQueue. So you have to accept/merge each time...just sayin'.
>
> I completely agree with that. Python wiki restricted all people of editing
> and now it is AFP. There should be a way with more flexible control over
> workflow. ApprovalQueue could only be used to moderate first edit and
> should be fast, so that people from IRC can approve edits quickly.
>
> There is some ready to use piece of code that is possible to adopt
> assuming that there is a sane amount of hackers who are not hacking
> on SCons code ATM or need a rest
> https://github.com/zacharyvoase/markdoc/network
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] What to replace the wiki with?

[Gary Oberbrunner]

On Fri, Dec 12, 2014 at 5:34 PM, Bill Deegan 
wrote:

> You can pair that with this javascript/jquery based browser based wiki..
> http://dynalon.github.io/mdwiki/#!index.md
>
> -Bill
>

Interesting... the point of that is to provide theming and richer content I
take it?  It doesn't provide an editor, but maybe the built-in github
editor would continue to work.

(Their FAQ does say it's hard to make the pages crawlable, and I do think
that's important.)


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] What to replace the wiki with?

[Gary Oberbrunner]

On Fri, Dec 12, 2014 at 2:14 PM, yegle  wrote:

> On Fri, Dec 12, 2014 at 11:08 AM, Gary Oberbrunner
>  wrote:
> > It's possible.  There's no online editor there, however, which I think
> will
> > limit the contributions to the "wiki".
>
> Yes there is, for every file in github, you can click on the small
> edit button on the up right corner, which will bring you to something
> like https://github.com/golang/go/edit/master/README.md Github will
> automatically fork that repo for you and submit a PR on your behave.


Aha, I didn't know that!  Nice.  The previewer looks good, and even marks
your changes in the margin.

(A little odd that it has to fork the repo for you, but it kind of makes
sense.)

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] What to replace the wiki with?

[Gary Oberbrunner]

On Fri, Dec 12, 2014 at 1:44 PM, yegle  wrote:

> On Fri, Dec 12, 2014 at 10:32 AM, Gary Oberbrunner
>  wrote:
> > You're thinking I want to move _everything_ to github I bet.  Actually,
> no.
> > I do like git better than mercurial, it's true; but bitbucket seems to
> have
> > fine git support these days so I'm agnostic on that. I really just want
> to
> > get the wiki back up soon, and not have to think about it anymore for a
> > while :-).  If someone proposes some other code-oriented wiki site I'd be
> > just as happy to use that for the wiki.
>
> How about host the markdown files in github, and publish them using
> Github Pages?
>

It's possible.  There's no online editor there, however, which I think will
limit the contributions to the "wiki".
-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] What to replace the wiki with?

[Gary Oberbrunner]

On Fri, Dec 12, 2014 at 1:20 PM, Dirk Bächle  wrote:

> On 12.12.2014 18:43, Gary Oberbrunner wrote:
>
>>
>> [...]
>>
>>
>> It would be a little odd to have our code at bitbucket and our wiki at
>> github, but if github's wiki engine/editor is way better, I'd consider it.
>> After all our wiki has been a separate thing for years already.
>>
>>  Ahh, I can already see where you're going with this  ;)
>
> You're thinking I want to move _everything_ to github I bet.  Actually,
no.  I do like git better than mercurial, it's true; but bitbucket seems to
have fine git support these days so I'm agnostic on that. I really just
want to get the wiki back up soon, and not have to think about it anymore
for a while :-).  If someone proposes some other code-oriented wiki site
I'd be just as happy to use that for the wiki.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] What to replace the wiki with?

[Gary Oberbrunner]

On Fri, Dec 12, 2014 at 11:16 AM, Dirk Bächle  wrote:

> Gary,
>
> On 12.12.2014 15:00, Gary Oberbrunner wrote:
>
>> I would like to find a system that has some kind of online
>> editor/previewer, rather than a pure clone/edit/push/pull-request system
>> (whether it's git or hg), because sometimes you want to see how your markup
>> will actually look on the site before pushing it.  (Dirk, I think that
>> would also help the "occasional contributor" overhead you're concerned
>> about.)  I do think something hg or git-based would be preferable.
>>
> sounds acceptable. What I'm mainly after is that a user can queue his
> changes...and then forget about them. So he doesn't have to cycle through
> all kinds of review steps, or answer further inquiries. That might put
> people off...
> It should be "edit", "save/commit"...done.
>
>> And yes, we have to move it off our current hosting provider because DoS
>> attacks on our MoinMoin wiki bring the shared server to its knees on a
>> somewhat regular basis.  And I'm not ready to be sysadmin of another amazon
>> micro instance, so we need a hosted solution.
>>
>>  Do we have admin access to the host where our website is running on?
> What is it exactly, apached? I just stumbled over this module
>
> http://www.techrepublic.com/blog/smb-technologist/secure-
> your-apache-server-from-ddos-slowloris-and-dns-injection-attacks/
>

No, sadly we don't.   Just .htaccess.  And I don't think our problems stem
from those kinds of things, though perhaps the first one would help, I
don't know.  A lot of it is fake account creation attempts and other probes
based on knowing it's a moinmoin wiki.


> , not sure if it could really help.
>
>  Anyway, I have the existing wiki mostly converted from moin to markdown
>> (github flavor, but I could redo it as a different flavor depending on what
>> we choose) with only a few hand edits necessary.  Some things like the
>> Bug() macro won't translate, but I think we can live without that.  I
>> didn't find any decent tools to convert from moin to rst, so I think going
>> with a markdown solution would be easier than rst at this point, though I
>> think pandoc can convert between markdown and rst, so if needed we can do
>> that -- not sure how lossy that conversion would be.
>>
> There is also Creole ( http://en.wikipedia.org/wiki/Creole_(markup) ),
> which is supported by Bitbucket. I have no personal experience with it, but
> it seems to be designed for exactly this purpose of migrating from one Wiki
> to another
>

 I didn't find any translators from moinmoin to creole.  I don't think
pandoc can go from markdown (what I have now) to creole yet.  BItbucket
also supports markdown though, so if we want to do that it would be easy
(technically).  Some folks in this discussion seemed to think it wasn't
great, I don't know.  Since I have the markdown pages (or will by the
weekend), I can try pushing up a repo as a bb wiki and we can see how we
like it.

It would be a little odd to have our code at bitbucket and our wiki at
github, but if github's wiki engine/editor is way better, I'd consider it.
After all our wiki has been a separate thing for years already.

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] What to replace the wiki with?

[Gary Oberbrunner]

I would like to find a system that has some kind of online
editor/previewer, rather than a pure clone/edit/push/pull-request system
(whether it's git or hg), because sometimes you want to see how your markup
will actually look on the site before pushing it.  (Dirk, I think that
would also help the "occasional contributor" overhead you're concerned
about.)  I do think something hg or git-based would be preferable.  And
yes, we have to move it off our current hosting provider because DoS
attacks on our MoinMoin wiki bring the shared server to its knees on a
somewhat regular basis.  And I'm not ready to be sysadmin of another amazon
micro instance, so we need a hosted solution.

Anyway, I have the existing wiki mostly converted from moin to markdown
(github flavor, but I could redo it as a different flavor depending on what
we choose) with only a few hand edits necessary.  Some things like the
Bug() macro won't translate, but I think we can live without that.  I
didn't find any decent tools to convert from moin to rst, so I think going
with a markdown solution would be easier than rst at this point, though I
think pandoc can convert between markdown and rst, so if needed we can do
that -- not sure how lossy that conversion would be.

So that's the state of the wiki world at this point.  I'll try to make
progress over the weekend but am not sold on a particular solution;
bitbucket seems like the easiest path right now but I'm open to other
possibilities if they meet the above criteria.


On Fri, Dec 12, 2014 at 4:12 AM, anatoly techtonik 
wrote:

> I think we just need hosting with better protection.
>
> On Fri, Dec 12, 2014 at 3:09 AM, Dirk Bächle  wrote:
> > Bill,
> >
> >
> > On 12.12.2014 00:52, Bill Deegan wrote:
> >
> > I'm thinking a hg repo and some sort of ci to process it when new changes
> > come in.
> > Or use readthedocs.org (It has integration with bitbucket for such
> already)
> >
> > That way users and do pull requests and also the webserver only has to
> > handle serving static pages.
> >
> > Is it reasonable to expect that users who wanted to contribute to
> wiki-like
> > content could handle mercurial?
> >
> > it's probably not so much about hg (or any other tool, for that matter),
> but
> > about the workflow that's required for getting one's changes in. To me it
> > feels like we're moving away from a more "scratchpad"-like medium, to
> static
> > pages. That would be okay if we had several authors and technical writers
> > that could create lots of pages with content. But this would mean that we
> > provide all the information, and we are responsible for keeping things
> > alive.
> > If that's what we want, fine.
> > It more or less boils down to the question: Do we want a Wiki (static
> pages)
> > for us, or for our users?
> >
> > Just some late night thoughts, to fuel the discussion...
> >
> > Regards,
> >
> > Dirk
> >
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
>
>
>
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Contribution to SCons development.

[Gary Oberbrunner]

On Sat, Dec 6, 2014 at 1:03 PM,  wrote:

> I found one here:
> http://computer-programming-forum.com/56-python/46da865fb41a1dc3.htm
>
> Ansible worked on that as well:
> https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/basic.py
>
> (_symbolic_mode_to_octal, _apply_operation_to_mode, 
> _get_octal_mode_from_symbolic_perms)
>

Good detective work!  The second is a bit more modern in style, but they
both seem workable.

-- Gary


>
>
> Le 6 déc. 2014 à 16:24, Gary Oberbrunner  a écrit :
>
>
>
> On Sat, Dec 6, 2014 at 9:37 AM, Shreedhar Manek 
> wrote:
>
>> 256 is octal 0400, so it looks like it's only getting the S_IRUSR part.
>>>> And that's because I steered you wrong; these are bitmasks, so you have to
>>>> use bitwise OR:  S_IRUSR | S_IRGRP | S_IROTH
>>>>
>>>
>> This was it. Thanks!
>>
>> Should I replace *all *integers with their counterpart string? Or only
>> select ones?
>>
>
> Well, first, don't forget your real goal is to allow SCons users to
> actually use a *string* to set the mode bits.  These constants you're
> using are in the 'stat' module (so 'import stat' will fix your bug below),
> but they are still numeric absolute constants.
>
> I think the original issue (
> http://scons.tigris.org/issues/show_bug.cgi?id=2494) asks for allowing
> users to use actual strings like the chmod command-line utility, which
> allows relative modes like "ug+rw,o-rwx" as well as numeric absolute modes
> like "777" (that's still a string, note). (see the chmod man page, for
> instance http://linux.die.net/man/1/chmod.)  SCons users could already
> just do 'import stat' and use the named constants, but those are absolute;
> the desired chmod modes are *relative *to the current state.  The main
> task for this issue is, I think, to parse those relative modes (relative to
> the file's current state) and compute the desired final mode.
>
> If you can write a function parse_mode_string(mode_string,
> original_mode_bits), that's 90% of the work.  (Actually I'm surprised there
> isn't one already written out there somewhere.)
>
> -- Gary
>
>
>> Replacing the first 0777 with S_IRWXU | S_IRWXG | S_IRWXO in
>>
>> test.write('SConstruct', """
>> Execute(Chmod('f1', 0666))
>> Execute(Chmod(('f1-File'), 0666))
>> Execute(Chmod('d2', S_IRWXU | S_IRWXG | S_IRWXO))
>> Execute(Chmod(Dir('d2-Dir'), 0777))
>> def cat(env, source, target):
>> target = str(target[0])
>> f = open(target, "wb")
>> for src in source:
>> f.write(open(str(src), "rb").read())
>> f.close()
>> Cat = Action(cat)
>> env = Environment()
>> env.Command('bar.out', 'bar.in', [Cat,
>>   Chmod("f3", 0666),
>>   Chmod("d4", 0777)])
>> env = Environment(FILE = 'f5')
>> env.Command('f6.out', 'f6.in', [Chmod('$FILE', 0666), Cat])
>> env.Command('f7.out', 'f7.in', [Cat,
>> Chmod('Chmod-$SOURCE', 0666),
>> Chmod('${TARGET}-Chmod', 0666)])
>>
>> # Make sure Chmod works with a list of arguments
>> env = Environment(FILE = 'f9')
>> env.Command('f8.out', 'f8.in', [Chmod(['$FILE', File('f10')], 0666),
>> Cat])
>> Execute(Chmod(['d11', Dir('d12')], 0777))
>> """)
>>
>> gives the following error,
>>
>> STDERR
>> =
>> NameError: name 'S_IRWXU' is not defined:
>>   File "/tmp/testcmd.23013.se_zJm/SConstruct", line 4:
>> Execute(Chmod('d2', S_IRWXU | S_IRWXG | S_IRWXO))
>>
>> FAILED test of /home/shrox/scons/src/script/scons.py
>> at line 598 of /home/shrox/scons/QMTest/TestCommon.py (_complete)
>> from line 701 of /home/shrox/scons/QMTest/TestCommon.py (run)
>> from line 390 of /home/shrox/scons/QMTest/TestSCons.py (run)
>> from line 123 of test/Chmod.py
>>
>>
>>
>> --
>> Shreedhar Manek
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>
>
> --
> Gary
>  ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Contribution to SCons development.

[Gary Oberbrunner]

On Sat, Dec 6, 2014 at 9:37 AM, Shreedhar Manek 
wrote:

> 256 is octal 0400, so it looks like it's only getting the S_IRUSR part.
>>> And that's because I steered you wrong; these are bitmasks, so you have to
>>> use bitwise OR:  S_IRUSR | S_IRGRP | S_IROTH
>>>
>>
> This was it. Thanks!
>
> Should I replace *all *integers with their counterpart string? Or only
> select ones?
>

Well, first, don't forget your real goal is to allow SCons users to
actually use a *string* to set the mode bits.  These constants you're using
are in the 'stat' module (so 'import stat' will fix your bug below), but
they are still numeric absolute constants.

I think the original issue (
http://scons.tigris.org/issues/show_bug.cgi?id=2494) asks for allowing
users to use actual strings like the chmod command-line utility, which
allows relative modes like "ug+rw,o-rwx" as well as numeric absolute modes
like "777" (that's still a string, note). (see the chmod man page, for
instance http://linux.die.net/man/1/chmod.)  SCons users could already just
do 'import stat' and use the named constants, but those are absolute; the
desired chmod modes are *relative *to the current state.  The main task for
this issue is, I think, to parse those relative modes (relative to the
file's current state) and compute the desired final mode.

If you can write a function parse_mode_string(mode_string,
original_mode_bits), that's 90% of the work.  (Actually I'm surprised there
isn't one already written out there somewhere.)

-- Gary


> Replacing the first 0777 with S_IRWXU | S_IRWXG | S_IRWXO in
>
> test.write('SConstruct', """
> Execute(Chmod('f1', 0666))
> Execute(Chmod(('f1-File'), 0666))
> Execute(Chmod('d2', S_IRWXU | S_IRWXG | S_IRWXO))
> Execute(Chmod(Dir('d2-Dir'), 0777))
> def cat(env, source, target):
> target = str(target[0])
> f = open(target, "wb")
> for src in source:
> f.write(open(str(src), "rb").read())
> f.close()
> Cat = Action(cat)
> env = Environment()
> env.Command('bar.out', 'bar.in', [Cat,
>   Chmod("f3", 0666),
>   Chmod("d4", 0777)])
> env = Environment(FILE = 'f5')
> env.Command('f6.out', 'f6.in', [Chmod('$FILE', 0666), Cat])
> env.Command('f7.out', 'f7.in', [Cat,
> Chmod('Chmod-$SOURCE', 0666),
> Chmod('${TARGET}-Chmod', 0666)])
>
> # Make sure Chmod works with a list of arguments
> env = Environment(FILE = 'f9')
> env.Command('f8.out', 'f8.in', [Chmod(['$FILE', File('f10')], 0666), Cat])
> Execute(Chmod(['d11', Dir('d12')], 0777))
> """)
>
> gives the following error,
>
> STDERR
> =
> NameError: name 'S_IRWXU' is not defined:
>   File "/tmp/testcmd.23013.se_zJm/SConstruct", line 4:
> Execute(Chmod('d2', S_IRWXU | S_IRWXG | S_IRWXO))
>
> FAILED test of /home/shrox/scons/src/script/scons.py
> at line 598 of /home/shrox/scons/QMTest/TestCommon.py (_complete)
> from line 701 of /home/shrox/scons/QMTest/TestCommon.py (run)
> from line 390 of /home/shrox/scons/QMTest/TestSCons.py (run)
> from line 123 of test/Chmod.py
>
>
>
> --
> Shreedhar Manek
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Contribution to SCons development.

[Gary Oberbrunner]

On Sat, Dec 6, 2014 at 4:35 AM, Shreedhar Manek 
wrote:

>
>>> I change the integer the equivalent string in chmod.py (eg. 0444
>>> to S_IRWXU and S_IRWXG and S_IRWXO) but there is problem ahead into the
>>> program and the test fails at this point -
>>>
>>
>> Watch out, 0444 is not the same as  S_IRWXU and S_IRWXG and S_IRWXO,
>> which would be  because of the "and"s. 0444 is S_IRUSR or S_IRGRP or
>> S_IROTH.
>>
>>>
>>>
> Ah, of course. Thanks!
>
>
>
>> s = S_IMODE(os.stat(test.workpath('f1'))[ST_MODE])
>>> test.fail_test(s != 0444)
>>>
>>> What do I do about this?
>>>
>>
>> How does it fail?  What is the value of s at that point?
>>
>
> The value of s at that point in decimal is 256. I cannot figure why
> though, as the only change that I've made is switching 0444 by S_IRUSR or
> S_IRGRP or S_IROTH.
>
> 256 is octal 0400, so it looks like it's only getting the S_IRUSR part.
And that's because I steered you wrong; these are bitmasks, so you have to
use bitwise OR:  S_IRUSR | S_IRGRP | S_IROTH

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Contribution to SCons development.

[Gary Oberbrunner]

On Thu, Dec 4, 2014 at 4:39 PM, Shreedhar Manek 
wrote:

> I need help with adapting tests.
>

Hi!

>
> I change the integer the equivalent string in chmod.py (eg. 0444
> to S_IRWXU and S_IRWXG and S_IRWXO) but there is problem ahead into the
> program and the test fails at this point -
>

Watch out, 0444 is not the same as  S_IRWXU and S_IRWXG and S_IRWXO, which
would be  because of the "and"s. 0444 is S_IRUSR or S_IRGRP or S_IROTH.

>
> s = S_IMODE(os.stat(test.workpath('f1'))[ST_MODE])
> test.fail_test(s != 0444)
>
> What do I do about this?
>

How does it fail?  What is the value of s at that point?

-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev