[Scons-dev] SCons Tool Format 2 (Plan)

[anatoly techtonik]

Hellou,

I am thinking about how to clean up mess with tools. There are two
things that could be done in parallel:

1.  give information about what is going with --debugs=tool(s)

 * avoid standard logging module, because it is hugs and
   may decrease SCons startup time
 * important points - tool subsystem initialization start,
   default tools lookup start, default tool cheking, default
   tools lookup end, explicit tool request in Environment
   lookup start/check/end, registration of the Tool API
 * -v --verbose option to give more details (-v is currently
   for --version, and is not used often)

2.  make SCons know which stuff tool provides: which
 builders (Capitalized methods to the Environment),
 for which extensions, which construction variables,
 what else I forgot?

 * this will allow to detect conflict, tools for c files,
   building mini-graph of the stuff, etc.

 * the tool should just expose what it provides in a
   module properties

 * the requirement to describe its behavior may be
   strict for core tools, but not for external stuff by
   default to keep the joy of hacking

 * registration of the Tool API - tracing what tool
   defines and what it actually declared after
   generate() completed (we can do this already,
   right?)

 * monitoring of Tool behavior - that tool modifies
   the stuff it declared, detect the stuff it touches
   (writes, but reads may also be useful), race
   conditions with other tools (overwriting each
   other's variables?), monitoring communication
   between tools through construction variables,
   monitor evolution and usage of construction
   variable

First approximation:

tool_provides = dict(
  scons_builders = 'Program',
  scons_extensions = '.c',  # or should it be 'source-masks'?
...
)

Other idea is to provide tool description in more human
friendly form in parseable module block:
"""
---[description v2]---
name: nasm
type: scons
provides:
  scons.builders: Program
  scons.extensions: .c
"""

For the reference, current public tool API:

def generate(env):
"""Add Builders and construction variables for {{ Tool }} to an
Environment."""
def exists(env):
"" Detect Tool is present"""


Does it sound like a plan? =)

P.S. Sorry for the big text. It started with a tiny idea and then it
grow up on me during the writing, and now I barely can resist sending
it.
-- 
anatoly t.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Re PR #171

[anatoly techtonik]

On Sun, Aug 31, 2014 at 8:54 PM, Gary Oberbrunner  wrote:
> On Sun, Aug 31, 2014 at 1:42 PM, Russel Winder  wrote:
>>
>> The whole ASCII string / Unicode codepoint sequence thing brings the
>> Python 2/Python 3 thing to a head. If we want a codebase that runs under
>> both Python 2 and Python 3 then we almost certainly have to use six to
>> provide the indirection layer for things like strings (unless we write
>> our own). Alternatively the Python 3 codebase can be separate (which is
>> what Anatoly was advocating if I remember correctly) and then do careful
>> cherry picks from the Python 2 codebase.
>
> six.py is now included in the python3 branch.  At this point not everything
> works (still a long way from it) but I see no showstopping issues that have
> cropped up yet.  (By showstopping I mean something that would prevent
> shipping a single codebase that works in 2.7 and 3.x.)

With new workflow can you rebase Python 3 changes on top of current
HEAD so that it becomes a single lineage of commits and make them
drafts? This way everybody can see what it takes to go Python 3 step by
step. (Too bad there are no hostings that support Evolve extension yet).

Have also tried https://github.com/python-modernize/python-modernize ?
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Re PR #171

[Gary Oberbrunner]

On Mon, Sep 8, 2014 at 4:16 AM, anatoly techtonik 
wrote:

> On Sun, Aug 31, 2014 at 8:54 PM, Gary Oberbrunner 
> wrote:
> > On Sun, Aug 31, 2014 at 1:42 PM, Russel Winder 
> wrote:
> >>
> >> The whole ASCII string / Unicode codepoint sequence thing brings the
> >> Python 2/Python 3 thing to a head. If we want a codebase that runs under
> >> both Python 2 and Python 3 then we almost certainly have to use six to
> >> provide the indirection layer for things like strings (unless we write
> >> our own). Alternatively the Python 3 codebase can be separate (which is
> >> what Anatoly was advocating if I remember correctly) and then do careful
> >> cherry picks from the Python 2 codebase.
> >
> > six.py is now included in the python3 branch.  At this point not
> everything
> > works (still a long way from it) but I see no showstopping issues that
> have
> > cropped up yet.  (By showstopping I mean something that would prevent
> > shipping a single codebase that works in 2.7 and 3.x.)
>
> With new workflow can you rebase Python 3 changes on top of current
> HEAD so that it becomes a single lineage of commits and make them
> drafts?


So far I have just merged the default branch into python3 periodically
rather
than rebasing it onto default, which would change the commit IDs.  This
seems OK so far.


> This way everybody can see what it takes to go Python 3 step by
> step. (Too bad there are no hostings that support Evolve extension yet).
>
> Have also tried https://github.com/python-modernize/python-modernize ?
>

The python3 branch already has had 2to3 run on it, as the very first step I
believe.
What does python-modernize add?  It says it's a very thin shim around 2to3.

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

Re: [Scons-dev] Re PR #171

[anatoly techtonik]

On Mon, Sep 8, 2014 at 12:56 PM, Gary Oberbrunner  wrote:
> On Mon, Sep 8, 2014 at 4:16 AM, anatoly techtonik 
> wrote:
>>
>> On Sun, Aug 31, 2014 at 8:54 PM, Gary Oberbrunner 
>> wrote:
>> > On Sun, Aug 31, 2014 at 1:42 PM, Russel Winder 
>> > wrote:
>> >>
>> >> The whole ASCII string / Unicode codepoint sequence thing brings the
>> >> Python 2/Python 3 thing to a head. If we want a codebase that runs
>> >> under
>> >> both Python 2 and Python 3 then we almost certainly have to use six to
>> >> provide the indirection layer for things like strings (unless we write
>> >> our own). Alternatively the Python 3 codebase can be separate (which is
>> >> what Anatoly was advocating if I remember correctly) and then do
>> >> careful
>> >> cherry picks from the Python 2 codebase.
>> >
>> > six.py is now included in the python3 branch.  At this point not
>> > everything
>> > works (still a long way from it) but I see no showstopping issues that
>> > have
>> > cropped up yet.  (By showstopping I mean something that would prevent
>> > shipping a single codebase that works in 2.7 and 3.x.)
>>
>> With new workflow can you rebase Python 3 changes on top of current
>> HEAD so that it becomes a single lineage of commits and make them
>> drafts?
>
> So far I have just merged the default branch into python3 periodically
> rather
> than rebasing it onto default, which would change the commit IDs.  This
> seems OK so far.

I doubt that it is possible to do a good review of the ported code, but it will
at least make it more suitable for review. In ideal world there should be
incremental enhancements so that the final Python 3 merge won't end up
with FUBAR.

>> This way everybody can see what it takes to go Python 3 step by
>> step. (Too bad there are no hostings that support Evolve extension yet).
>>
>> Have also tried https://github.com/python-modernize/python-modernize ?
>
> The python3 branch already has had 2to3 run on it, as the very first step I
> believe.
> What does python-modernize add?  It says it's a very thin shim around 2to3.

2to3 makes code incompatible with Python 2.

With modernize it is possible to go one fixer at a time and bisect errors later.
-- 
anatoly t.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Re PR #171

[Gary Oberbrunner]

On Mon, Sep 8, 2014 at 6:35 AM, anatoly techtonik 
wrote:

> 2to3 makes code incompatible with Python 2.
>
> With modernize it is possible to go one fixer at a time and bisect errors
> later.
>

I believe individual fixers were applied and python2 compatibility has been
added back in a piece at a time.  It's not complete but a lot of tests pass
both on python2 and python3.  You can try it.  Patches gratefully accepted!

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

Re: [Scons-dev] Re PR #171

[anatoly techtonik]

On Mon, Sep 8, 2014 at 1:52 PM, Gary Oberbrunner  wrote:
> On Mon, Sep 8, 2014 at 6:35 AM, anatoly techtonik 
> wrote:
>>
>> 2to3 makes code incompatible with Python 2.
>>
>> With modernize it is possible to go one fixer at a time and bisect errors
>> later.
>
> I believe individual fixers were applied and python2 compatibility has been
> added back in a piece at a time.  It's not complete but a lot of tests pass
> both on python2 and python3.  You can try it.  Patches gratefully accepted!

Yesterday I wasted about 4 hours debugging issues with Python 3 listed as:
http://bugs.python.org/issue20731
http://bugs.python.org/issue20844
and one more issue about py.ini
and I am not sure that I want to continue dealing with this can of worms.

I only wish that all bad modifications can be back traced and reverted and for
that they need to come in small chunks in project history, and its good when
the branch point is based on single state during review, i.e. without merges.
-- 
anatoly t.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Re PR #171

[Gary Oberbrunner]

On Mon, Sep 8, 2014 at 7:03 AM, anatoly techtonik 
wrote:

>
> Yesterday I wasted about 4 hours debugging issues with Python 3 listed as:
> http://bugs.python.org/issue20731
> http://bugs.python.org/issue20844
> and one more issue about py.ini
>

If they are python bugs, is there anything we can do to work around them?
What OS and python version were you using?

and I am not sure that I want to continue dealing with this can of worms.
>

OK, fine to leave it for someone else then.

I only wish that all bad modifications can be back traced and reverted and
> for
> that they need to come in small chunks in project history, and its good
> when
> the branch point is based on single state during review, i.e. without
> merges.


That sounds like a wonderful goal.  I doubt it's achievable in practice.
 'hg annotate' should help with what you're asking about; yes you may have
to do a few hops to get the original author but I doubt that will dominate
the debugging time for any particular bug.

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

Re: [Scons-dev] This morning's WTF moment

[Kenny, Jason L]

I know that I am late in the talk here and some of this may have been answered 
already..

Windows has a sub-systems that run on the kernel. One of them is win32. ( there 
used to be a posix one FYI, and with win 8 there is a new winrt layer).  So 
while it looks like a joke to on windows 64-bit to see win32 as a platform it 
is technically correct.. This is why I pushed a while ago to get 
(TARGET|HOST)_(OS|ARCH) added to SCons. I know that when this was proposed 
there had been different takes on what to do. .. ie do we have one object deal 
with this, or do we make different variable to deal with this. There are plus 
and minus to but cased for different use cases. This is why I added to Part the 
SystemPlatform object. To main goal is to enhance the target and host idea from 
the simple Scons PLATFORM concept. I believe this has been a great addition. 
And should be added in some way to SCon, it is a basic building block to make 
cross platform builds work better and to help make it easy to define more 
complex toolchain setups in an easy way.

At anyrate SCons  current imple of the tool should be fixed to correct the 
warning issue. The way I have some people fix this with Parts is to have them 
add a scons-site directory with an empty tools/defaults.py. 

Jason

-Original Message-
From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Russel Winder
Sent: Saturday, September 6, 2014 4:43 AM
To: SCons_Developers
Subject: [Scons-dev] This morning's WTF moment

OK so I am abandoning all my scruples and trying to get SCons running on my 
wife's Windows 7 machine so as to run some tests on Linux, OSX *and* Windows.

I have now discovered that on a 64-bit laptop running Windows 7:

Environment()['PLATFORM']

return win32. One assumes there is some existentialist humour present in this 
result?

Also at every turn I am told:

scons: warning: No version of Visual Studio compiler found – C/C++ compilers 
most likely not set correctly File … engine\SCons\Script\Main.py", line 602, in 
_scons_internal_warning

Yes I know this, I haven't installed any C or C++ compilers on this machine, I 
don't need to be told at every turn. However not only does SCons insists on 
telling me this, it tells me twice, at Reading SConscript files phase *AND* 
Building targets phase.
 
--
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

Re: [Scons-dev] Re PR #171

[Neal Becker]

anatoly techtonik wrote:

> On Mon, Sep 8, 2014 at 12:56 PM, Gary Oberbrunner
>  wrote:
>> On Mon, Sep 8, 2014 at 4:16 AM, anatoly techtonik
>>  wrote:
>>>
>>> On Sun, Aug 31, 2014 at 8:54 PM, Gary Oberbrunner
>>>  wrote:
>>> > On Sun, Aug 31, 2014 at 1:42 PM, Russel Winder
>>> >  wrote:
>>> >>
>>> >> The whole ASCII string / Unicode codepoint sequence thing brings the
>>> >> Python 2/Python 3 thing to a head. If we want a codebase that runs
>>> >> under
>>> >> both Python 2 and Python 3 then we almost certainly have to use six to
>>> >> provide the indirection layer for things like strings (unless we write
>>> >> our own). Alternatively the Python 3 codebase can be separate (which is
>>> >> what Anatoly was advocating if I remember correctly) and then do
>>> >> careful
>>> >> cherry picks from the Python 2 codebase.
>>> >
>>> > six.py is now included in the python3 branch.  At this point not
>>> > everything
>>> > works (still a long way from it) but I see no showstopping issues that
>>> > have
>>> > cropped up yet.  (By showstopping I mean something that would prevent
>>> > shipping a single codebase that works in 2.7 and 3.x.)
>>>
>>> With new workflow can you rebase Python 3 changes on top of current
>>> HEAD so that it becomes a single lineage of commits and make them
>>> drafts?
>>
>> So far I have just merged the default branch into python3 periodically
>> rather
>> than rebasing it onto default, which would change the commit IDs.  This
>> seems OK so far.
> 
> I doubt that it is possible to do a good review of the ported code, but it
> will at least make it more suitable for review. In ideal world there should be
> incremental enhancements so that the final Python 3 merge won't end up
> with FUBAR.
> 
>>> This way everybody can see what it takes to go Python 3 step by
>>> step. (Too bad there are no hostings that support Evolve extension yet).
>>>
>>> Have also tried https://github.com/python-modernize/python-modernize ?
>>
>> The python3 branch already has had 2to3 run on it, as the very first step I
>> believe.
>> What does python-modernize add?  It says it's a very thin shim around 2to3.
> 
> 2to3 makes code incompatible with Python 2.
> 
> With modernize it is possible to go one fixer at a time and bisect errors
> later.

Take a look at future package:
https://pypi.python.org/pypi/future/0.13.0

-- 
-- Those who don't understand recursion are doomed to repeat it

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

Re: [Scons-dev] This morning's WTF moment

[Kenny, Jason L]

SO I am all for improving the Tools logic. This was a big part of the work I 
did in Parts. Given what I have, I know there are some more tweaks I would like 
to make.

Is there a process in how to add proposal to this wiki page. I know I would 
like to propose a possible infra set of objects to make it easier to find and 
set up a working tools environment. ( ie what is need to run command correctly)

Also a general statement. Do we want to say SCons errors or warns when a tool 
in a toolchain is not found. I have taken a view that it should error out with 
information. ( for example the user might have stated they want icc v12.1, 
parts might error out given that it is not installed tell the user that 13.1 
was found not 12.1). I have found that warnings turn to noise more often than 
not and are ignored ( or missed as the text just scrolls to fast). When the 
“error” does happen later ( and it will) the user is annoyed that had time 
wasted.

For me it seems to me that is a toolchain is not resolvable we need to error.

I would also state that we want to allow define one toolchain per env. Some 
toolchains cannot be mixed. And having a different env just makes it work 
better. D and C++ seems to a common case here. However this is more complex, as 
different chains could be mixed as they are independent. Being able to define 
what toolchain to use up front, vs having a default chain ( which takes time 
and is a result of certain annoying warning on windows at time) seem to be a 
good solution, as we can provide chains, and allow then chain to complain is 
there are known incompatible issues.

Jason



From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Gary 
Oberbrunner
Sent: Saturday, September 6, 2014 8:09 AM
To: SCons developer list
Subject: Re: [Scons-dev] This morning's WTF moment


On Sat, Sep 6, 2014 at 8:41 AM, anatoly techtonik 
mailto:techto...@gmail.com>> wrote:
> I disagree.  I am currently taking action on it.  There is some
> documentation on the wiki describing my direction, and I'm writing some test
> code to explore further.

I am afraid you're the only one who knows what you're doing. =) If you
could paste a reference to this specific wiki location, I could change
my mind, but so far I am definitely not in the list of people who are
able to track this progress.

http://www.scons.org/wiki/ToolchainRevamp (and related sub-pages).  There was 
some mailing list discussion which I wanted to cut and paste into the 
discussion page but didn't get around to that yet.  Admittedly this is not 100% 
up to date but it describes the general approach I'm investigating.

I have a separate repo where I'm working on some test implementations, starting 
with a basic test framework for a new Tool base class and a ToolRegistry (my 
tasks for this weekend if I can get enough time).  But it's nowhere near ready 
to share, which is why I just posted some pseudocode on that wiki page.  I need 
to strike a balance between sharing the design and being transparent so people 
can give feedback, and trying things out.

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

[Scons-dev] 2.3.3 Release issue ?

[Alexandre Feblot]

Hi,

Would there be a release issue with 2.3.3 ?

Downloaded from http://prdownloads.sourceforge.net/scons/scons-2.3.3.tar.gz

Installed by python setup.py install --prefix /usr/local --optimize 2
--symlink-scons

scons --version
SCons by Steven Knight et al.:
script: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
engine: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
engine path: ['/usr/local/lib/scons-2.3.3/SCons']
Copyright (c) 2001 - 2014 The SCons Foundation


EnsureSConsVersion() just prints:


*scons: warning: EnsureSConsVersion is ignored for development version*
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] 2.3.3 Release issue ?

[anatoly techtonik]

On Mon, Sep 8, 2014 at 7:41 PM, Alexandre Feblot  wrote:
> Hi,
>
> Would there be a release issue with 2.3.3 ?
>
> Downloaded from http://prdownloads.sourceforge.net/scons/scons-2.3.3.tar.gz
>
> Installed by python setup.py install --prefix /usr/local --optimize 2
> --symlink-scons
>
> scons --version
> SCons by Steven Knight et al.:
> script: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
> engine: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
> engine path: ['/usr/local/lib/scons-2.3.3/SCons']
> Copyright (c) 2001 - 2014 The SCons Foundation
>
>
> EnsureSConsVersion() just prints:
>
> scons: warning: EnsureSConsVersion is ignored for development version

Yes. This is a bug:

   def EnsureSConsVersion(self, major, minor, revision=0):
   """Exit abnormally if the SCons version is not late enough."""
   if SCons.__version__ == '2.3.3':
   SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning,

This should be:

   def EnsureSConsVersion(self, major, minor, revision=0):
   """Exit abnormally if the SCons version is not late enough."""
   if SCons.__version__ == '__VERSION__':
   SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning,

The __VERSION__ of course was replaced during our build process. The
quick fix is:
-   if SCons.__version__ == '__VERSION__':
+   if SCons.__version__ == '__' + 'VERSION__':
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] 2.3.3 Release issue ?

[anatoly techtonik]

I wonder why buildbots are silent about this?

On Mon, Sep 8, 2014 at 8:25 PM, anatoly techtonik  wrote:
> On Mon, Sep 8, 2014 at 7:41 PM, Alexandre Feblot  wrote:
>> Hi,
>>
>> Would there be a release issue with 2.3.3 ?
>>
>> Downloaded from http://prdownloads.sourceforge.net/scons/scons-2.3.3.tar.gz
>>
>> Installed by python setup.py install --prefix /usr/local --optimize 2
>> --symlink-scons
>>
>> scons --version
>> SCons by Steven Knight et al.:
>> script: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
>> engine: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
>> engine path: ['/usr/local/lib/scons-2.3.3/SCons']
>> Copyright (c) 2001 - 2014 The SCons Foundation
>>
>>
>> EnsureSConsVersion() just prints:
>>
>> scons: warning: EnsureSConsVersion is ignored for development version
>
> Yes. This is a bug:
>
>def EnsureSConsVersion(self, major, minor, revision=0):
>"""Exit abnormally if the SCons version is not late enough."""
>if SCons.__version__ == '2.3.3':
>SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning,
>
> This should be:
>
>def EnsureSConsVersion(self, major, minor, revision=0):
>"""Exit abnormally if the SCons version is not late enough."""
>if SCons.__version__ == '__VERSION__':
>SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning,
>
> The __VERSION__ of course was replaced during our build process. The
> quick fix is:
> -   if SCons.__version__ == '__VERSION__':
> +   if SCons.__version__ == '__' + 'VERSION__':



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

Re: [Scons-dev] 2.3.3 Release issue ?

[anatoly techtonik]

Anyway we need to wait when Gary is available to wrap a new release
with this fix. Is there anybody else who can release?

On Mon, Sep 8, 2014 at 8:27 PM, anatoly techtonik  wrote:
> I wonder why buildbots are silent about this?
>
> On Mon, Sep 8, 2014 at 8:25 PM, anatoly techtonik  wrote:
>> On Mon, Sep 8, 2014 at 7:41 PM, Alexandre Feblot  wrote:
>>> Hi,
>>>
>>> Would there be a release issue with 2.3.3 ?
>>>
>>> Downloaded from http://prdownloads.sourceforge.net/scons/scons-2.3.3.tar.gz
>>>
>>> Installed by python setup.py install --prefix /usr/local --optimize 2
>>> --symlink-scons
>>>
>>> scons --version
>>> SCons by Steven Knight et al.:
>>> script: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
>>> engine: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
>>> engine path: ['/usr/local/lib/scons-2.3.3/SCons']
>>> Copyright (c) 2001 - 2014 The SCons Foundation
>>>
>>>
>>> EnsureSConsVersion() just prints:
>>>
>>> scons: warning: EnsureSConsVersion is ignored for development version
>>
>> Yes. This is a bug:
>>
>>def EnsureSConsVersion(self, major, minor, revision=0):
>>"""Exit abnormally if the SCons version is not late enough."""
>>if SCons.__version__ == '2.3.3':
>>SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning,
>>
>> This should be:
>>
>>def EnsureSConsVersion(self, major, minor, revision=0):
>>"""Exit abnormally if the SCons version is not late enough."""
>>if SCons.__version__ == '__VERSION__':
>>SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning,
>>
>> The __VERSION__ of course was replaced during our build process. The
>> quick fix is:
>> -   if SCons.__version__ == '__VERSION__':
>> +   if SCons.__version__ == '__' + 'VERSION__':
>
>
>
> --
> anatoly t.



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

Re: [Scons-dev] 2.3.3 Release issue ?

[Alexandre Feblot]

Thx for pinpointing the issue location, anyway. I fixed my own in the
meantime.

2014-09-08 19:47 GMT+02:00 anatoly techtonik :

> Anyway we need to wait when Gary is available to wrap a new release
> with this fix. Is there anybody else who can release?
>
> On Mon, Sep 8, 2014 at 8:27 PM, anatoly techtonik 
> wrote:
> > I wonder why buildbots are silent about this?
> >
> > On Mon, Sep 8, 2014 at 8:25 PM, anatoly techtonik 
> wrote:
> >> On Mon, Sep 8, 2014 at 7:41 PM, Alexandre Feblot 
> wrote:
> >>> Hi,
> >>>
> >>> Would there be a release issue with 2.3.3 ?
> >>>
> >>> Downloaded from
> http://prdownloads.sourceforge.net/scons/scons-2.3.3.tar.gz
> >>>
> >>> Installed by python setup.py install --prefix /usr/local --optimize 2
> >>> --symlink-scons
> >>>
> >>> scons --version
> >>> SCons by Steven Knight et al.:
> >>> script: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
> >>> engine: v2.3.3, 2014/08/24 12:12:31, by garyo on lubuntu
> >>> engine path: ['/usr/local/lib/scons-2.3.3/SCons']
> >>> Copyright (c) 2001 - 2014 The SCons Foundation
> >>>
> >>>
> >>> EnsureSConsVersion() just prints:
> >>>
> >>> scons: warning: EnsureSConsVersion is ignored for development version
> >>
> >> Yes. This is a bug:
> >>
> >>def EnsureSConsVersion(self, major, minor, revision=0):
> >>"""Exit abnormally if the SCons version is not late enough."""
> >>if SCons.__version__ == '2.3.3':
> >>SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning,
> >>
> >> This should be:
> >>
> >>def EnsureSConsVersion(self, major, minor, revision=0):
> >>"""Exit abnormally if the SCons version is not late enough."""
> >>if SCons.__version__ == '__VERSION__':
> >>SCons.Warnings.warn(SCons.Warnings.DevelopmentVersionWarning,
> >>
> >> The __VERSION__ of course was replaced during our build process. The
> >> quick fix is:
> >> -   if SCons.__version__ == '__VERSION__':
> >> +   if SCons.__version__ == '__' + 'VERSION__':
> >
> >
> >
> > --
> > 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] This morning's WTF moment

[William Blevins]

Conceptually, I like Jason's suggestions.  I don't know how the 1 toolchain
per env would work in practice.  What about SWIG or JNI or other mixed
builds?
On Sep 8, 2014 12:19 PM, "Kenny, Jason L"  wrote:

>  SO I am all for improving the Tools logic. This was a big part of the
> work I did in Parts. Given what I have, I know there are some more tweaks I
> would like to make.
>
>
>
> Is there a process in how to add proposal to this wiki page. I know I
> would like to propose a possible infra set of objects to make it easier to
> find and set up a working tools environment. ( ie what is need to run
> command correctly)
>
>
>
> Also a general statement. Do we want to say SCons errors or warns when a
> tool in a toolchain is not found. I have taken a view that it should error
> out with information. ( for example the user might have stated they want
> icc v12.1, parts might error out given that it is not installed tell the
> user that 13.1 was found not 12.1). I have found that warnings turn to
> noise more often than not and are ignored ( or missed as the text just
> scrolls to fast). When the “error” does happen later ( and it will) the
> user is annoyed that had time wasted.
>
>
>
> For me it seems to me that is a toolchain is not resolvable we need to
> error.
>
>
>
> I would also state that we want to allow define one toolchain per env.
> Some toolchains cannot be mixed. And having a different env just makes it
> work better. D and C++ seems to a common case here. However this is more
> complex, as different chains could be mixed as they are independent. Being
> able to define what toolchain to use up front, vs having a default chain (
> which takes time and is a result of certain annoying warning on windows at
> time) seem to be a good solution, as we can provide chains, and allow then
> chain to complain is there are known incompatible issues.
>
>
>
> Jason
>
>
>
>
>
>
>
> *From:* Scons-dev [mailto:scons-dev-boun...@scons.org] *On Behalf Of *Gary
> Oberbrunner
> *Sent:* Saturday, September 6, 2014 8:09 AM
> *To:* SCons developer list
> *Subject:* Re: [Scons-dev] This morning's WTF moment
>
>
>
>
>
> On Sat, Sep 6, 2014 at 8:41 AM, anatoly techtonik 
> wrote:
>
> > I disagree.  I am currently taking action on it.  There is some
> > documentation on the wiki describing my direction, and I'm writing some
> test
> > code to explore further.
>
> I am afraid you're the only one who knows what you're doing. =) If you
> could paste a reference to this specific wiki location, I could change
> my mind, but so far I am definitely not in the list of people who are
> able to track this progress.
>
>
> http://www.scons.org/wiki/ToolchainRevamp (and related sub-pages).  There
> was some mailing list discussion which I wanted to cut and paste into the
> discussion page but didn't get around to that yet.  Admittedly this is not
> 100% up to date but it describes the general approach I'm investigating.
>
>
>
> I have a separate repo where I'm working on some test implementations,
> starting with a basic test framework for a new Tool base class and a
> ToolRegistry (my tasks for this weekend if I can get enough time).  But
> it's nowhere near ready to share, which is why I just posted some
> pseudocode on that wiki page.  I need to strike a balance between sharing
> the design and being transparent so people can give feedback, and trying
> things out.
>
>
>
> --
> 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

Re: [Scons-dev] 2.3.3 Release issue ?

[Gary Oberbrunner]

Grr.  Oh well.

On Mon, Sep 8, 2014 at 1:47 PM, anatoly techtonik 
wrote:

> Anyway we need to wait when Gary is available to wrap a new release
> with this fix. Is there anybody else who can release?
>

I'm here, but am pretty busy at the moment.  This weekend I will be away.
 Please start by making a pull request with the fix.


> On Mon, Sep 8, 2014 at 8:27 PM, anatoly techtonik 
> wrote:
> > I wonder why buildbots are silent about this?
>

Good question, if we need a new test as part of the test suite please add
it to the patch.

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

Re: [Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Mon, Sep 8, 2014 at 12:19 PM, Kenny, Jason L 
wrote:

>  SO I am all for improving the Tools logic. This was a big part of the
> work I did in Parts. Given what I have, I know there are some more tweaks I
> would like to make.
>
>
>
> Is there a process in how to add proposal to this wiki page. I know I
> would like to propose a possible infra set of objects to make it easier to
> find and set up a working tools environment. ( ie what is need to run
> command correctly)
>
>
>
> Also a general statement. Do we want to say SCons errors or warns when a
> tool in a toolchain is not found. I have taken a view that it should error
> out with information. ( for example the user might have stated they want
> icc v12.1, parts might error out given that it is not installed tell the
> user that 13.1 was found not 12.1). I have found that warnings turn to
> noise more often than not and are ignored ( or missed as the text just
> scrolls to fast). When the “error” does happen later ( and it will) the
> user is annoyed that had time wasted.
>
>
>
> For me it seems to me that is a toolchain is not resolvable we need to
> error.
>

The current proposal is that a Tool's exists() should _return_ an error
message but not throw or print anything.  The toolchain logic above it can
then test silently and decide what to do.

>
>
> I would also state that we want to allow define one toolchain per env.
> Some toolchains cannot be mixed. And having a different env just makes it
> work better. D and C++ seems to a common case here. However this is more
> complex, as different chains could be mixed as they are independent. Being
> able to define what toolchain to use up front, vs having a default chain (
> which takes time and is a result of certain annoying warning on windows at
> time) seem to be a good solution, as we can provide chains, and allow then
> chain to complain is there are known incompatible issues.
>
>
> The current proposal is that a Toolchain is either AND (all must exist) or
OR (first one wins).  Toolchains can have other toolchains as members as
well as Tools.  Any element in a Toolchain can be marked as Optional (which
means if it's in an AND toolchain it doesn't fail that toolchain if it
doesn't exist).  I have some simple test code for this working.

I hope this architecture is flexible enough that we can have one master
toolchain per system; that one would have sub-toolchains for C/C++ (which
would consist of an OR toolchain for Intel, MSVC, gcc/mingw, gcc/cygwin and
whatever else we want), SWIG, D, LaTeX, and whatever else we want.  I'm
also hoping (don't have any of this working or even really designed yet) to
make it easy enough to replace or add to the default toolchain that we can
make the default pretty minimal; users would add what they need.

I also think it's flexible enough to give decent and appropriate error
messages when the toolchain requirements aren't met.

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

Re: [Scons-dev] This morning's WTF moment

[Kenny, Jason L]

I should clarify that by toolchain I literally mean chain of tools that 
coexist.. What interesting about this is that a java toolchain or a c toolchain 
are a chain of tools by themselves, but can also be composed as one bigger 
chain. When I think of D and C/C++ ( or fortran and C/C++) I think chains that 
can coexist, but a tool in the chain may need to behave differently ( ie the 
linker), or we might want to have a special tool to replace the default link 
tool. There are other cases in which seem obvious to me at time, but I see 
confused a lot, is that we have a C tool chain for different compilers, ie the 
GCC toolchain has a compiler and linker in it, but the CC and LINK vars for GCC 
are very different than the ones used for MSVC or intelc or Clang. These have 
different default flags and configuration added as well completely different 
binaries and shell environments. So from a technical point of view I know in 
Parts I would want to look at tools chains as maybe having an notion of 
variations, ie CC.CL or CC.GCC or CC.INTEL. with certain properties to control 
how the variation is configured. ie I wanted to change the parts 
–toolchain=tool_ver logic to a –toolchain=[[@properity:value…],…] 
set up..  ie --tc=cc.cl@version:12  or for intel 
compiler something like  
--tc=cc.icl@ver:13.*,mstools@ver:12 
 which would setup latest version of 13 to work with msvc version 12 ( ie VS 
2013)

Just some thought I have had…

Jason


From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of William 
Blevins
Sent: Monday, September 8, 2014 1:47 PM
To: SCons developer list
Subject: Re: [Scons-dev] This morning's WTF moment


Conceptually, I like Jason's suggestions.  I don't know how the 1 toolchain per 
env would work in practice.  What about SWIG or JNI or other mixed builds?
On Sep 8, 2014 12:19 PM, "Kenny, Jason L" 
mailto:jason.l.ke...@intel.com>> wrote:
SO I am all for improving the Tools logic. This was a big part of the work I 
did in Parts. Given what I have, I know there are some more tweaks I would like 
to make.

Is there a process in how to add proposal to this wiki page. I know I would 
like to propose a possible infra set of objects to make it easier to find and 
set up a working tools environment. ( ie what is need to run command correctly)

Also a general statement. Do we want to say SCons errors or warns when a tool 
in a toolchain is not found. I have taken a view that it should error out with 
information. ( for example the user might have stated they want icc v12.1, 
parts might error out given that it is not installed tell the user that 13.1 
was found not 12.1). I have found that warnings turn to noise more often than 
not and are ignored ( or missed as the text just scrolls to fast). When the 
“error” does happen later ( and it will) the user is annoyed that had time 
wasted.

For me it seems to me that is a toolchain is not resolvable we need to error.

I would also state that we want to allow define one toolchain per env. Some 
toolchains cannot be mixed. And having a different env just makes it work 
better. D and C++ seems to a common case here. However this is more complex, as 
different chains could be mixed as they are independent. Being able to define 
what toolchain to use up front, vs having a default chain ( which takes time 
and is a result of certain annoying warning on windows at time) seem to be a 
good solution, as we can provide chains, and allow then chain to complain is 
there are known incompatible issues.

Jason



From: Scons-dev 
[mailto:scons-dev-boun...@scons.org] On 
Behalf Of Gary Oberbrunner
Sent: Saturday, September 6, 2014 8:09 AM
To: SCons developer list
Subject: Re: [Scons-dev] This morning's WTF moment


On Sat, Sep 6, 2014 at 8:41 AM, anatoly techtonik 
mailto:techto...@gmail.com>> wrote:
> I disagree.  I am currently taking action on it.  There is some
> documentation on the wiki describing my direction, and I'm writing some test
> code to explore further.

I am afraid you're the only one who knows what you're doing. =) If you
could paste a reference to this specific wiki location, I could change
my mind, but so far I am definitely not in the list of people who are
able to track this progress.

http://www.scons.org/wiki/ToolchainRevamp (and related sub-pages).  There was 
some mailing list discussion which I wanted to cut and paste into the 
discussion page but didn't get around to that yet.  Admittedly this is not 100% 
up to date but it describes the general approach I'm investigating.

I have a separate repo where I'm working on some test implementations, starting 
with a basic test framework for a new Tool base class and a ToolRegistry (my 
tasks for this weekend if I can get enough time).  But it's nowhere near ready 
to share, which is why I just posted some pseudocode on that wiki page.  I need 
to strike a balance between s

Re: [Scons-dev] This morning's WTF moment

[Kenny, Jason L]

Question on the exists()

Ideally I always viewed this as a True False statement. I see you have it 
returning a tuple.

I only worry that I have seen a lot push with certain python developers to say 
stuff like

if not tool.exists():
# do something…

This will not work as we will have a (True,””) or (False,””) return API. This 
seems to me to more complex to use and understand. At the very least east to 
trip up on. If we want an object returned. I think it will be better to define 
a error object that can be tested as True or False vs forcing tuple separation 
on returns values.

Jason
From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Gary 
Oberbrunner
Sent: Monday, September 8, 2014 2:57 PM
To: SCons developer list
Subject: Re: [Scons-dev] This morning's WTF moment



On Mon, Sep 8, 2014 at 12:19 PM, Kenny, Jason L 
mailto:jason.l.ke...@intel.com>> wrote:
SO I am all for improving the Tools logic. This was a big part of the work I 
did in Parts. Given what I have, I know there are some more tweaks I would like 
to make.

Is there a process in how to add proposal to this wiki page. I know I would 
like to propose a possible infra set of objects to make it easier to find and 
set up a working tools environment. ( ie what is need to run command correctly)

Also a general statement. Do we want to say SCons errors or warns when a tool 
in a toolchain is not found. I have taken a view that it should error out with 
information. ( for example the user might have stated they want icc v12.1, 
parts might error out given that it is not installed tell the user that 13.1 
was found not 12.1). I have found that warnings turn to noise more often than 
not and are ignored ( or missed as the text just scrolls to fast). When the 
“error” does happen later ( and it will) the user is annoyed that had time 
wasted.

For me it seems to me that is a toolchain is not resolvable we need to error.

The current proposal is that a Tool's exists() should _return_ an error message 
but not throw or print anything.  The toolchain logic above it can then test 
silently and decide what to do.

I would also state that we want to allow define one toolchain per env. Some 
toolchains cannot be mixed. And having a different env just makes it work 
better. D and C++ seems to a common case here. However this is more complex, as 
different chains could be mixed as they are independent. Being able to define 
what toolchain to use up front, vs having a default chain ( which takes time 
and is a result of certain annoying warning on windows at time) seem to be a 
good solution, as we can provide chains, and allow then chain to complain is 
there are known incompatible issues.

The current proposal is that a Toolchain is either AND (all must exist) or OR 
(first one wins).  Toolchains can have other toolchains as members as well as 
Tools.  Any element in a Toolchain can be marked as Optional (which means if 
it's in an AND toolchain it doesn't fail that toolchain if it doesn't exist).  
I have some simple test code for this working.

I hope this architecture is flexible enough that we can have one master 
toolchain per system; that one would have sub-toolchains for C/C++ (which would 
consist of an OR toolchain for Intel, MSVC, gcc/mingw, gcc/cygwin and whatever 
else we want), SWIG, D, LaTeX, and whatever else we want.  I'm also hoping 
(don't have any of this working or even really designed yet) to make it easy 
enough to replace or add to the default toolchain that we can make the default 
pretty minimal; users would add what they need.

I also think it's flexible enough to give decent and appropriate error messages 
when the toolchain requirements aren't met.

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

Re: [Scons-dev] This morning's WTF moment

[Gary Oberbrunner]

On Mon, Sep 8, 2014 at 4:13 PM, Kenny, Jason L 
wrote:

> Ideally I always viewed this as a True False statement. I see you have it
> returning a tuple.
>
>
>
> I only worry that I have seen a lot push with certain python developers to
> say stuff like
>
>
>
> if not tool.exists():
>
> # do something…
>
>
>
> This will not work as we will have a (True,””) or (False,””) return API.
> This seems to me to more complex to use and understand. At the very least
> east to trip up on. If we want an object returned. I think it will be
> better to define a error object that can be tested as True or False vs
> forcing tuple separation on returns values.
>

Excellent point.  The 'if not tool.exists()' pattern needs to work.  I'll
rethink that.  Maybe something as simple as tool.exist_error() which can be
called just after exists() returns False...

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

Re: [Scons-dev] This morning's WTF moment

[William Blevins]

This might be obvious, but it the exception pattern not popular in python?
On Sep 8, 2014 9:19 PM, "Gary Oberbrunner"  wrote:

>
> On Mon, Sep 8, 2014 at 4:13 PM, Kenny, Jason L 
> wrote:
>
>> Ideally I always viewed this as a True False statement. I see you have it
>> returning a tuple.
>>
>>
>>
>> I only worry that I have seen a lot push with certain python developers
>> to say stuff like
>>
>>
>>
>> if not tool.exists():
>>
>> # do something…
>>
>>
>>
>> This will not work as we will have a (True,””) or (False,””) return API.
>> This seems to me to more complex to use and understand. At the very least
>> east to trip up on. If we want an object returned. I think it will be
>> better to define a error object that can be tested as True or False vs
>> forcing tuple separation on returns values.
>>
>
> Excellent point.  The 'if not tool.exists()' pattern needs to work.  I'll
> rethink that.  Maybe something as simple as tool.exist_error() which can be
> called just after exists() returns False...
>
> --
> 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