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

[Dirk Bächle]

Hi Gary,

On 10.01.2016 16:05, Gary Oberbrunner wrote:


On Sun, Jan 10, 2016 at 4:26 AM, Dirk Bächle <tshor...@gmx.de 
<mailto:tshor...@gmx.de>> 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.



if all you other core devs feel this way, then I'm not opposed to the idea. Feel free to switch to "git" anytime, and I will adapt 
to it. My goal with asking for reference projects was to be able to point to a benefit for the whole project...and not only for 
single contributors. But there really seems to be enough momentum behind this decision to just go with the "gut feelings" of you 
all...so be it then.


Best regards,

Dirk

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

Re: [Scons-dev] Ubuntu buildbot available

[Dirk Bächle]

Hi there,

On 10.01.2016 20:47, Bill Deegan wrote:

Try adding:
gettext-base  to resolve the skipped gettext tests
rpm  to resolve skipped rpm tests
flex  to resolve lex..

I think that's all the ones I'm sure of.

Dirk -  Sugguestions on how to get the TEX and DocBook ones running?



looks like the failing TeX testcases aren't protected properly against not having "latex" installed and in the $PATH. Not sure if 
you really want to go that route and install a full TeXLive version (or similar).

For DocBook you would need to install the XSLT stylesheets and put a link to 
them from

  /usr/share/xml/docbook/stylesheet/docbook-xsl

and also install the Python XML bindings libxml2/libxslt or lxml, respectively.

Best regards,

Dirk

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

Re: [Scons-dev] Shipping one time migration scripts with SCons

[Dirk Bächle]

Hi Anatoly,

On 01.02.2016 20:14, anatoly techtonik wrote:

Hi,

There is an interesting thread, which needs some
consensus.
https://bitbucket.org/scons/scons/pull-requests/302/change-the-cache-to-use-2-character/



"consensus" between whom? And what is your concrete idea about how this consensus should be reached? It looks to me as if the issue 
has been properly discussed among the people that are actively working on the pull request...and they've reached a consensus already.

One that I support too, I might add...


I am against shipping global scripts that are not
generally useful to all scons users, but it seems
that nobody agrees.



Yes, I see that you have concerns and your position is on the one side of the scale. But the guys that have done all the hard work 
have a position too, which happens to be different from yours (=other side of the scale). This happens, please don't take offense 
over it and get upset.


Best regards,

Dirk

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

Re: [Scons-dev] Missing Wiki page on pkg-config

[Dirk Bächle]

Hi,

On 31.01.2016 13:23, anatoly techtonik wrote:

Hi,

https://bitbucket.org/scons/scons/wiki/ParseConfig is missing,
referenced from
https://bitbucket.org/scons/scons/wiki/UsingPkgConfig



hint: ParseConfig is described in the UserGuide.

Best regards,

Dirk


By the way, is there a tool for SCons that can do the job of
pkg-config? Looks like it is a simple parser, no?


Depends on what it is exactly that you're trying to parse under Windows for example, How do you plan to get at the required infos 
about which header and libs to include?


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

Re: [Scons-dev] Python 3 strategy

[Dirk Bächle]

Hi there,

On 25.01.2016 10:39, Russel Winder wrote:

I am having difficulty making a decision…

The earlier Python 3 branch is founded on using six. At the time a good
decision. Now however we have agreed that 2.7 is the base version and
thus future rather than six is the better tool for Python 3. This
brings into doubt the python3-port branch as a good base of operations.



here's my 2 cents: For me the major point is to have a combined Python2.7/3.x version at all, and if you guys (thinking of Russel 
and William right now) get the impression that starting from scratch with "futurize" is the better plan...please do so. You're doing 
the hard work towards this goal at the moment, so you should be free to decide how to get there, in my opinion.

And if this means that some users will later on complain about the dependency to 
"futurize", well I'd let it happen...
I see a greater overall benefit for the project in getting "some work done", than in "discussing things to death, due to fear of the 
unknown". ;)
I'd second Gary, you might want to have a short look at his change sets...and if you still feel like starting from scratch 
afterwards, just go for it.


Best regards,

Dirk

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

Re: [Scons-dev] Python3 activity

[Dirk Bächle]

Hi Vasily,

On 25.01.2016 21:39, Vasily wrote:

Any answer to my question about the place and approach for stubprocess to live 
in?

Thanks,
Vasily

16 янв. 2016 г. 0:17 пользователь "Vasily" > написал:

I have started looking into the docs for integrating stubprocess in there.

My current thoughts are to put it as a separate file next to posix.py in 
"Platform", any objections to this approach? Should I
maybe put it to "compat"?



sorry for not coming back to you about this question. The "platform" folder is fine, just put the new module file there. Thanks a 
lot for working on this!


Best regards,

Dirk

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

Re: [Scons-dev] SCons default branch open for python 2.7/3.x work. Please submit pull requests

[Dirk Bächle]

Hi,

On 10.04.2016 20:56, Bill Deegan wrote:

All,

Here's what I propose.
1. Merge scons_python3 down to default.  It's o.k if it's broken for a bit. We 
can always do bug fixes out of rel_2.5.0 branch if
needed and merge those down.
2. I'm o.k. with many tests failing when merged down to default. Python 2/3 is 
a major project and move forward for SCons.  As far
as fixing those embedded code strings, I'd like to see a pull request per fix 
(so it's easy to review).   If we're talking about
moving them to the new test fixtures  (see: "working with fixtures" in
https://bitbucket.org/scons/scons/wiki/DeveloperGuide/TestingMethodology), I'm 
all for that.



+1 from me (as described in my latest mail to scons-dev). But we still need to fit "stubprocess.py" into the schedule 
somewhere...sorry for repeating this over and over again. But I still think it's crucial to have it, in order to finally shake off 
the "SCons is slow" rumours completely.


Regards,

Dirk

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

Re: [Scons-dev] scons-2.5.0 performance issue?

[Dirk Bächle]

Hi Thomas,

On 11.04.2016 16:59, Thomas Berg wrote:

Bill, below is the output of --debug=count, it is identical with
scons-2.4.1 and scons-2.5.0.

Since my case was about the no-op build (nothing is built), less
parallelization should not be an issue. ...


if you haven't already done so, you might want to try out my "fastcpp" 
extension at:

  https://bitbucket.org/dirkbaechle/scons_fastcpp

. It may give you some speedup, but please regard its disclaimer.

Best regards,

Dirk

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

Re: [Scons-dev] SCons and Python 3

[Dirk Bächle]

Hi Russel,

On 10.04.2016 13:10, Russel Winder wrote:

The python3-port currently has:

47 test fails
108 no results

[...]

Sorry I didn't get much done on this over the last 12 weeks, long (and
tedious) story – which no-one is interested in.



you have done a lot...by starting the task and keeping development and the discussion about it alive. Thanks for all the effort 
you've put into this so far!


Best regards,

Dirk

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

Re: [Scons-dev] SCons PDF docs

[Dirk Bächle]

Hi Bill,

On 11.04.2016 23:43, Bill Deegan wrote:

Dirk or anyone else super familiar with the doc toolchain,


Is it possible to generate the docs with PDF bookmarks?
(something like this : http://www.sagehill.net/docbookxsl/PdfBookmarks.html)

It would be great to be able to navigate more easily.



yes that's very easy to accomplish. Just add the following parameter to the 
"pdf.xsl" of each document:

--- a/doc/user/pdf.xsl  Sat Apr 09 19:04:42 2016 -0400
+++ b/doc/user/pdf.xsl  Tue Apr 12 01:29:26 2016 +0200
@@ -33,6 +33,7 @@

 
 
+
 
 
 0pt



Note how this is only correct for the FOP renderer, but I guess that's the only one we have at the moment...at least when building a 
release, right?


Best regards,

Dirk

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

Re: [Scons-dev] python3-port branch merged to default and then closed

[Dirk Bächle]

On 24.05.2016 20:04, Bill Deegan wrote:

Dirk,

Please do.

Probably the right place to post this issue anyway.. Maybe I'll sign up for the 
list.
Assuming it's fairly high traffic?



That's right...I'll probably unsubscribe soon, but haven't decided yet.

Dirk


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

Re: [Scons-dev] python3-port branch merged to default and then closed

[Dirk Bächle]

Hi there,

On 24.05.2016 10:54, Alexandre Feblot wrote:

Hi,
definitely not a guru. I did this once, which was enough to get a python file 
loaded, and access its classes:

import importlib.machinery
my_module = importlib.machinery.SourceFileLoader('my_module', 
'/path/to/my_module.py').load_module()
My_Class = my_module.My_Class
my_class_instance = my_module.My_Class()



on the python-list there was a post/question about this (or at least related) 
today:

  https://mail.python.org/pipermail/python-list/2016-May/709388.html


Maybe someone answers...should I bring that to your attention then (I'm 
currently subscribed)?

Best regards,

Dirk


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

Re: [Scons-dev] Hg vs Git

[Dirk Bächle]

Hi Mark,

On 10.05.2016 04:21, Mark A. Flacy wrote:

Hmm.

I've used (in order, more or less), PLS (which I expect nobody to know), 
Clearcase, RCS, CVS, Arch, TLA, HG, BZR, and Git. I won't
claim to have used svn in any real sense.

The first 4 of that list were centralized version control systems and so not 
applicable to this discussion.

Of arch, tla, hg, bzr, and git, I'd say that I enjoyed bzr over hg for a rather 
long time. Now that I've used git, I think that git
has the correct distributed model over hg and bzr.

Once you realize that git doesn't require history to be immutable (but once 
you've shared history, you have a problem if you change
it), you'll find that you can do a lot of things that simply are not possible 
with hg and bzr. (That's not entirely true; the patch
queue for hg allowed you to do some things that you can do with git but with a 
tremendous amount of pain.)

Mr. Bächle, you should try to use git for a couple of your internal projects.



No need to get formal... ;)

I am using git for several projects (some own and some open-source), and I don't mind it. As I tried to explain before, I'm not 
opposed to making the switch to git for the SCons repo...but I'm trying to make sure that we're doing it for the right reasons.


And when single persons claim that there is a "hindrance" for them in contributing to SCons currently, because there's so much 
syntax that is hard to remember I start to wonder: with how many issues at the same time are these users juggling? Because if one 
works on at most one bug at a time, one should be able to get away with a "linear series of commits":


  hg clone ...
  # edit
  hg commit
  hg pull / push

which are all the same as in git. One can even throw in a "hg add" and it won't hurt, but only remind you that the file is already 
under version control. ;)



It's not about my personal preferences, it's all about the project.

Best regards,

Dirk


P.S.: One of my personal preferences is: I *don't* want the history in my repos to be mutable...maybe that's why git doesn't seem to 
be so more powerful than hg to me, and why I still consider them to be "on par" regarding functionality. At least for the work I 
have to do with them...


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

Re: [Scons-dev] Hg vs Git

[Dirk Bächle]

Hi there,

On 09.05.2016 16: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.



and because you don't use an IDE (like Eclipse) that would support both
DVCS in a transparent fashion, and because you don't want to use a git-hg
bridge?


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.


I'm one of the latter category, and obviously a dying species ;) according to:

  http://two.pairlist.net/pipermail/scons-dev/2016-January/003374.html

Don't let me hinder progress, and feel free to switch to git at any time...but
I then won't be much of a help when it comes to updating the workflow 
descriptions
in the Wiki or helping out newcomers with DVCS problems.


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.




When we're talking about things like "effort" and "git as being less painful", 
I'd
like to renew my call for pointers to large open-source projects that have 
switched
to git as DVCS (from hg preferably):

  http://two.pairlist.net/pipermail/scons-dev/2016-January/003358.html

Does anyone have a concrete example of a project that experienced a giant 
productivity
boost, based on a switch of the DVCS?
I understand that for you, and Tim, using git it would be less of a hindrance 
to simply
"check in" the changes and extensions for SCons that you seem to have in the 
hopper.
But I'm interested in increasing activity in the "long run" for the project. ;)

So, if you say that you're planning to get an active contributor, ready to help out on the mailing lists and squashing a bug now and 
then...well, then you win me over pretty fast. :)



Finally, the obligatory pointers to the archives for this and related 
discussion(s):

  http://two.pairlist.net/pipermail/scons-dev/2016-January/003344.html
  http://two.pairlist.net/pipermail/scons-dev/2016-January/003352.html

Best regards,

Dirk

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

Re: [Scons-dev] User Guide and Other Release Documents

[Dirk Bächle]

William,

On 16.04.2016 22:43, William Blevins wrote:

Bill,

http://scons.org/doc/production/HTML/scons-user.html

Just search for ptomulik; it's everywhere.



I count 6 occurrences...which doesn't qualify as "everywhere" to me. ;)
Even more important, those strings are simply given in the source documentation file "gettext.xml". So it's not that the doc 
toolchain replaced some placeholder with the user's home directory by mistake, it's how the author of those lines intended the 
example to look like. Everything is as it should be...


I hope this lets you sleep well. ;)

Best regards,

Dirk

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

Re: [Scons-dev] Two questions…

[Dirk Bächle]

Hi,

On 14.04.2016 18:48, Bill Deegan wrote:

Russel,


[...]

Oh and…

3. Is there any reason why we should not switch from DocBook/XML to
Asciidoctor for all the documentation?


I'd like to postpone any discussion of the doc toolchain until after we get the 
python 3 work done, unless you strongly feel it's
urgent.



I'd like to second this. The issue has already been discussed in the past, and just like for "migrating the bugtracker away from 
Tigris" or "migrating the repo to git/github" I see the basic problem as follows: It's always easy to "talk the talk", but then you 
have to "walk the walk". People's plans seem to collapse at step 2 frequently. ;)


Best regards,

Dirk

___
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...

[Dirk Bächle]

Bill,

On 31.07.2016 23:17, Bill Deegan wrote:

Dirk,

On Sun, Jul 31, 2016 at 6:53 AM, Dirk Bächle <tshor...@gmx.de 
<mailto:tshor...@gmx.de>> wrote:


[...]

We need someway to indicate on stackoverflow that this is the intent or we'll 
get mired in a confusing mass of people expecting all
the documents to be in stackoverflow.. (Seeing this already)..




that's why new contributions and edits have to get approved first. And I wouldn't mind having a parallel stream of docs and examples 
in StackOverflow that we can directly refer to (or copy-paste nice examples from). I guess I simply don't see the final scenario 
that you seem to be concerned about. Can you be more specific?


After all, this is just the start of the SO documentation...so I expect an initial rush by a few contributors (early adopters), and 
after that it will be up to us (the SCons team) to fill in most of the infos there. And especially for the deep-knowledge parts 
there won't be a lot of people that are capable of describing how things work, let alone having the time to do so.


And don't forget: every reference and mentioning of the keyword "SCons" on the internet counts...this is really a kind of cheap PR 
for us if we manage to keep the SO docs going.


Best regards,

Dirk

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

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

[Dirk Bächle]

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

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

[Dirk Bächle]

On 31.07.2016 14:26, Gary Oberbrunner wrote:

Looks like I was the final vote!



Awesome! Big thanks to everyone who gave his vote!

Regards,

Dirk



On Jul 30, 2016 7:35 AM, "Dirk Bächle" <tshor...@gmx.de 
<mailto:tshor...@gmx.de>> 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 <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

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

[Dirk Bächle]

Bill,

On 01.08.2016 19:46, Bill Deegan wrote:

Should we pre-populate with all the current scons docs?



no I don't think so. I see this as a community effort, that we simply approve and watch such that no incorrect solutions or even 
rumours spread.
SO docs is still in beta phase, and from what I read in some of the Meta posts they are planning to revamp the whole "docs" 
reputation system.

Let's just see how this evolves over time and what good we can draw from it. ;)

What we could do though, and this possibly aims in the same direction as the concerns from your last mail, is to add a short 
description about SCons (our standard text) to the "docs" page. Perhaps with a disclaimer like:


"Note that these SCons documentation pages on SO are a community effort. If in 
doubt, the official reference for syntax and
usage of the SCons tool are the MAN page and User's Guide as published by the 
project (see also http://www.scons.org)."

, or something similar.

Regards,

Dirk


On Mon, Aug 1, 2016 at 12:22 AM, Dirk Bächle <tshor...@gmx.de 
<mailto:tshor...@gmx.de>> wrote:

Bill,

On 31.07.2016 23 <tel:31.07.2016%2023>:17, Bill Deegan wrote:

Dirk,

On Sun, Jul 31, 2016 at 6:53 AM, Dirk Bächle <tshor...@gmx.de 
<mailto:tshor...@gmx.de> <mailto:tshor...@gmx.de
<mailto:tshor...@gmx.de>>> wrote:


[...]

We need someway to indicate on stackoverflow that this is the intent or 
we'll get mired in a confusing mass of people
expecting all
the documents to be in stackoverflow.. (Seeing this already)..



that's why new contributions and edits have to get approved first. And I 
wouldn't mind having a parallel stream of docs and
examples in StackOverflow that we can directly refer to (or copy-paste nice 
examples from). I guess I simply don't see the final
scenario that you seem to be concerned about. Can you be more specific?

After all, this is just the start of the SO documentation...so I expect an 
initial rush by a few contributors (early adopters),
and after that it will be up to us (the SCons team) to fill in most of the 
infos there. And especially for the deep-knowledge
parts there won't be a lot of people that are capable of describing how 
things work, let alone having the time to do so.

And don't forget: every reference and mentioning of the keyword "SCons" on 
the internet counts...this is really a kind of cheap
PR for us if we manage to keep the SO docs going.

Best regards,

Dirk


___
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

Re: [Scons-dev] Fwd: [Scons-users] Performance of version 2.5.0 vs 2.3.0 on Windows host dropped significantly

[Dirk Bächle]

On 16.08.2016 18:36, Bill Deegan wrote:

Will do.
I'm trying to fix buildbot.scons.org/timings 
  as since the switch from SVN to mercurial 
the
revision numbers change to sha hashs and screwed up the display.
If Henrik's example provides a differing data point perhaps we can add it (or 
some obfuscated version of) to benchmark suite.



That was my idea too. Keep up the good work on this guys! :)

Regards,

Dirk


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

Re: [Scons-dev] User-guide generation

[Dirk Bächle]

Hi William,

I hope you don't mind since we're among developers here, but I think it's fair to apply the same rules to everyone. So I'm treating 
this the same as on the user list.
Please tell us which commands exactly you have run, and which parts of the documentation you follow as reference. The 
"doc/user/SConstruct" should work fine and is supposed to allow you to build the corresponding PDFs/HTMLs standalone, during editing 
for example.

So simply removing it is not an option at the moment.

Best regards,

Dirk


On 19.08.2016 06:32, William Blevins wrote:

Team,

While I was chasing my tail, I went ahead and followed the 
SimplifiedReleaseProcedure
.
 Not sure how to verify I did it right. What's the
process for handing out alphas?

I didn't make a branch or anything. This was just for my personal reference.

V/R,
William

On Fri, Aug 19, 2016 at 4:54 AM, William Blevins > wrote:

Team,

I think I chased my tail until I figured out I needed to run some python 
scripts under #bin which do fairy magic...

V/R,
William

On Fri, Aug 19, 2016 at 4:12 AM, William Blevins > wrote:

Team,

Is the doc/user/SConstruct legacy? If I build from #SConstruct then I 
seem to get some not insane in the build directory. If
doc/user/SConstruct is no longer functional or maintained, I would like 
to remove it to alleviate my confusion!

V/R,
William

On Fri, Aug 19, 2016 at 3:18 AM, William Blevins > wrote:

Team,

I have a strange issue. The user-guide build does not throw any 
errors but doc/user/index.html does not regenerate and
doc/user/scons-user/index.html is empty. All the addition html 
files under doc/user/scons-user seem to generate correctly.

Anyone else have this issue?

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

Re: [Scons-dev] User-guide generation

[Dirk Bächle]

William,

On 19.08.2016 13:14, William Blevins wrote:

Dirk,

Apparently, the user guide data doesn't regenerate unless you call:

python bin/docs-update-generated.py
python bin/docs-validate.py
python bin/docs-create-example-outputs.py

I guess it just doesn't make a lot of sense to me why these are manual steps 
rather than being commands that run as part of the
#doc/user build step.



please have another look at

  https://bitbucket.org/scons/scons/wiki/DeveloperGuide/Documentation

. The normal user, only doing simple edits and changing text passages, shouldn't have to care about regenerating the output of the 
examples. He can run the validate script, and then compile the user guide for example, such that he gets an idea how the final 
PDF/HTML output might look like.
Everything beyond this point is in the scope of the actual release team. This separation is there to make it as easy as possible for 
new contributors to add or amend documentation. The required validation ensures that the checked in and merged doc changes by a user 
can be compiled into a correct document later on by a release manager, sort of justifying the usage of Docbook all together.


I hope this makes things a little clearer.

Finally, the UserGuide should also get recompiled when you change one of the chapter *.xml files. If this doesn't happen that would 
clearly qualify as a bug...


Best regards,

Dirk

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

Re: [Scons-dev] User-guide generation

[Dirk Bächle]

Hi William,

On 20.08.2016 00:22, William Blevins wrote:

Dirk,

...

Right and I understand that there is documentation, and I use it when I have an 
issue. The problem that I have is that I have worked
with the docs more than most (outside the maintainer team), and I always seem 
to forget about the #bin scripts. In my opinion, a
good process is intuitive and doesn't have lots of manual steps. I think it 
would be a good idea to have the SConstruct in #doc/user
to Execute the #bin scripts in order. I don't think it would cause any issues, 
but would make generating the docs a 1-step process.
Is there a reason not to do something like this?



the main reason for this is, I guess, that the generation of examples needs a lot of time. And there are people out there that don't 
like seeing this step being repeated over and over again, whenever they make minor changes to the documents and want to receive 
"immediate" visual feedback.





. The normal user, only doing simple edits and changing text passages, 
shouldn't have to care about regenerating the output of
the examples. He can run the validate script, and then compile the user 
guide for example, such that he gets an idea how the
final PDF/HTML output might look like.
Everything beyond this point is in the scope of the actual release team. 
This separation is there to make it as easy as possible
for new contributors to add or amend documentation. The required validation 
ensures that the checked in and merged doc changes
by a user can be compiled into a correct document later on by a release 
manager, sort of justifying the usage of Docbook all
together.


I don't see the harm in a regular developer getting a generated document that 
reflects the changes made. If I make changes to
documents and regenerating the user guide doesn't show my changes, then it gets 
very puzzling.



I was talking about "the normal user" (read: occasional contributor), why do you now switch to what the "regular developer" can 
expect or not?

I understand that in your case both of these roles seem to coincide, but this 
is not true for the majority of people out there.



I hope this makes things a little clearer.

Finally, the UserGuide should also get recompiled when you change one of 
the chapter *.xml files. If this doesn't happen that
would clearly qualify as a bug...


It rebuilds. We may want to change the wiki documentation though, because 
python-lxml does not appear to work correctly with the
chunked guides index.html. I moved to python-libxml2 and python-libxslt1 and 
that seemed to make things happier.


Another option might be to find out *why* the python-lxml binding doesn't seem 
to work, and then make it doing so. ;)

Best regards,

Dirk

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

Re: [Scons-dev] Builder with custom decider and non-file based target

[Dirk Bächle]

Hi Oleg,

On 04.08.2016 13:55, Left Right wrote:

Hello list.

I'm trying to come up with a builder for Docker images. Docker images
are built based on a Dockerfile template and a bunch of other sources
one way or another related to the template. The output, however, isn't
a file strictly speaking. The builder should combine two Docker
operations: build+push, thus the final build artifact is the image
residing in Docker registry (a server with it's own database,
accessible via HTTP).

What I'd like to accomplish is the following:
1. Create Docker Builder s.t. given the Dockerfile and other auxiliary
files will call "docker build", then "docker push" to produce the
build artifact and to put it in the Docker registry.
2. Prevent building images if a query to Docker registry for a
previously built image succeeds.

I'm now looking at target_factory of SCons.Builder, but I'm not sure
this is the way to proceed. Please advise.



SCons works file-centric, meaning it expects that input and output to the single Builders (build steps) are actual files. So, as 
soon as you try to manage your images "proxy-wise" on a remote server you'll run into problems.

There is probably no easy workaround and you have to code the "remote" 
functionality in Python directly...

Best regards,

Dirk

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

Re: [Scons-dev] scons --tree=status raises an exception

[Dirk Bächle]

Hi Joel,

On 29.09.2016 16:25, Joel Ostraat wrote:

I chatted with Bill Deegan on IRC yesterday.  He encouraged me to file a bug 
report
(http://scons.tigris.org/issues/show_bug.cgi?id=3033) and ask how this might be 
fixed.  To reiterate my thoughts and questions from
the bug report:

Looking into it a little, I think that SCons.Node.FS.File.executor should never 
be None.  The uses of get_executor() prior to this
change seem to expect it to return either a valid Executor object, or raise an 
exception leaving the executor attribute non-existent.

I was able to prevent the problem by changing the line
https://bitbucket.org/scons/scons/commits/a8570fab2b7b2f3f1ce520528908904b9584e1f9#Lsrc/engine/SCons/Node/FS.pyT2786
 to
self.reset_executor() and removing a few other checks for "self.executor is 
None" also added in that commit.  But I don't know if
that's the right solution.

Perhaps there is some extra meaning meant to be conveyed when that executor 
attribute is be None.  If that's true, then there are
many other places where the return value of get_executor() should be checked 
against None.



welcome to the dev list! The log message (as well as the various 
comments/documentation around the changes) of the commit
a8570fab2b7b that you mention in your bug report, hint at what the change tries to accomplish. The executor is reset to "None", 
after building the target or finding that it's up-to-date, such that the garbage collector can free its memory. This is important in
large projects (10+ files) where the amount of memory used by the Executor objects reach a significant percentage and help to 
drive the whole build process into swapping much sooner.



I've been using SCons for a while, but know very little about the internals of 
SCons.  Any direction on how to fix this would be
appreciated.



If you see/can identify several other places and situations where a valid executor seems to be expected, they probably need a guard 
against "executor == None". Would you be able to have a look at that and try to come up with a pull request? That would be awesome.


Best regards,

Dirk

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

Re: [Scons-dev] Scons-dev Digest, Vol 57, Issue 9

[Dirk Bächle]

Hi Oleg,

thanks a lot for taking the time to write up your questions and suggestions. I'm really interested in hearing more about how you 
think SCons could be improved. You'll find some specific questions and comments inline below...


Please bear in mind that SCons is a file-centric build system, so it's designed around the idea of having files as input and output 
to the single build steps. In particular, you usually need a file (Node) to get at its contents for deciding whether the file has 
changed such that depending targets can get updated automatically.

Leading to the first question of how to decide whether a "directory" (given as 
source in your intended case) is up-to-date or not?
While answering this question, please take into account that possibly not all files that "live" in this folder physically exist yet. 
Some of them might get created (or updated) during the build process, but we still want SCons to handle dependencies on these files 
automatically such that we can guarantee a correct build for the user.


This is a tiny aspect of the "can of worms" ;) that you opened with your last email, but it shows that we are moving away from the 
actually intended usage of SCons and that you try to bend SCons the way you would like it to behave. It follows logically for me 
that you encounter problems and questions, and that a larger knowledge about SCons' internal workings is required in this case.
I would also expect that someone who is this interested in the "inner clockworks" at least tries to get at additional information by 
introducing his/her problem on the developer mailing list and asking for further advice and pointers to helpful documentation.

You have done 1), but 2)...well, not so much I'm afraid.
Leading me to my second upfront question: Which documentation have you read so far? (Please be specific, and name the title of the 
SCons documents, or give the URLs.) Did you find the ToolsForFools guide at https://bitbucket.org/scons/scons/wiki/ToolsForFools? Do 
you know that we have a document describing the underlying design of SCons, although it's a bit outdated?


Best regards,

Dirk

On 19.09.2016 09:08, Left Right wrote:

OK, after the dust settled, I regret the tone of the message, but
there's really nothing of interest in it for the users mailing list.

This is really intended for the developers of Scons.  For the last two
months I've been looking for a build tool to build two things: Go
programs and Docker images.  I've considered and even to some extent
wrote working builds in:
- SCons
- WAF
- Gradle
- tup
- Blaze
- Stag
I didn't really try to use Make, but it's not difficult to see how
that would fit into the picture.
The unfortunate conclusion is that all these "tools" are very poorly
engineered and some are also poorly executed.  They lack some obvious
basic functionality, they assume too much about what the user of the
tool is trying to do, impose arbitrary restrictions unrelated to the
task the user is trying to perform.  Of all of this collection SCons
appears to be the most tolerable option.  I don't suppose you are
interested in any sort of feedback on other tools, but there are some
thing you might reconsider about SCons.  This isn't about the user
experience, this is about the code of the program and about the
decisions which made it to be this way.

1. Classes with several dozens of methods.  There really shouldn't be this many.


Please point to a concrete example for this, and tell us how to improve. How many methods would be tolerable in your view, and why 
exactly would the SCons core benefit from it?



2. Comments and documentation are unhelpful.  They are written from
the perspective of someone who wrote the code, but they don't help the
reader.  There is no birds-eye overview of the system.  (But, compared
to the list above, at least you have some).


As mentioned in my reply above, we have such documentation as well...possibly spread across several places, but it exists. If you 
think the access to these informations should be made easier, please be our guest and make some concrete suggestions about how to 
restructure the existing texts and documentation in general. If, for example, you'd like to open a Wiki page with all the required 
pointers that seem necessary for what you have in mind, we can surely give you all the required access rights that you'd need for that.



3. Everything happens "by chance", when you read the code you always
need to guess the state of the object the method it is working with,
this is including the class of the object and the values of several
dozens of fields the object has: you pull a rope at one end, and from
the other end firebreathing dragons begin to emerge.


Yes, build systems are complex. (Sorry, I can't give a more specific answer to a vague 
statement like "everything happens by chance").


4. Object's functionality is encoded into strings which are passed
around at will and are next to impossible to track before 

Re: [Scons-dev] Python 2to3

[Dirk Bächle]

On 22.09.2016 19:21, William Blevins wrote:

The current PR is from default; I'm just using bookmarks.



Sorry, I hadn't noticed...all the better then. ;)

Dirk


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

Re: [Scons-dev] Python 2to3

[Dirk Bächle]

Hi William,

On 22.09.2016 05:39, William Blevins wrote:

Administrators,

I have a lot of stuff in that PR now. Look at it and decide if it's fine.



this looks great! Let's merge it as is, and then continue by opening another branch right away. Regarding the "fixture"s, it's okay 
with me if you skip this for simple one-liners...it's more important to have the tests working again in general.


I'm truly sorry for having to ask this, but I didn't follow the Py2to3 discussions that closely: Did we already merge in Tim 
Jenness' changes from


  https://github.com/timj/scons/tree/u/timj/python3

or is this still "tbd"?

Best regards,

Dirk

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

Re: [Scons-dev] Python 2to3

[Dirk Bächle]

On 22.09.2016 18:40, Dirk Bächle wrote:

Hi William,

On 22.09.2016 05:39, William Blevins wrote:

Administrators,

I have a lot of stuff in that PR now. Look at it and decide if it's fine.



this looks great! Let's merge it as is, and then continue by opening another 
branch right away.



...or, even better, switch to working from "default" (without named branches) again. From my angle, the main porting work is 
through...we've decided on a way to go forward, so it's probably justified to regard the upcoming commits for the Py2to3 work as 
"fixes".


Dirk


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

Re: [Scons-dev] User-guide generation

[Dirk Bächle]

Hi William,

On 21.08.2016 17:53, William Blevins wrote:


[...]

I would argue that "the normal user" never runs the document building scripts, 
so I don't see how that applies.


it applies because the building scripts, and the Doc toolchain, around it is especially designed and setup such that "the normal 
user" can run them without having to install too many additional dependencies. He doesn't get an updated example text or a refreshed 
Builder description, but if he simply edited or changed a paragraph in one of the chapters he certainly shouldn't mind.




As I said, I haven't been in this community long, so I don't know the history 
of SCons (not really). How and why were some decisions
made? As I work on the code, those questions aren't irrelevant. Text has this 
way of removing body language. I hope I don't sound
combative because that's not my intention. I just like being frank, and I like 
questions. I have a weird mix of software development
and tester experience, so questions just come with the territory. I also tend 
to use emails like others use instant messaging. I
think it comes with the age demographic. This tends to annoy people. Sorry :)



That's okay.

But what is the actual remaining problem that you would like to tackle? The docs rebuild when one of the chapter *.xml files change, 
which is what I'd call "correct behaviour".


Regards,

Dirk

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

[Scons-dev] Announcement: Break for my BuildBot slaves...

[Dirk Bächle]

Hi there,

just wanted to let you know: my BuildBot slaves will stay down for another month or so. I bought a house and will move there during 
the next month, so I hope to be able to revive them around mid of November.
I'll probably stay very quiet on the mailing lists as well (StackOverflow is an exception because I can reach it from work ;) ) 
during this time.


@TomTanner: Sorry for the delay, the refactorings for custom TaskMasters/NodeFactories/... aren't forgotten. I started to work on 
this and need just another week or so to flesh things out a bit. But I don't have a week at the moment...I guess it's going to be 
somewhere around start of December when I can present a first version as draft/pull request.


Please keep up the good work everybody! :)

Best regards,

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

Re: [Scons-dev] The Contrib Repository. [was Adding support for Visual Studio Code workspace generation]

[Dirk Bächle]

Hi,

here are my 2c... ;)

On 28.11.2016 10:36, Russel Winder wrote:

On Sun, 2016-11-27 at 12:42 -0800, Bill Deegan wrote:

Andrew,

If it's interesting to you, go ahead and work on it!
There's an index of community supported builders in the wiki. Feel
free to
add your work there (https://bitbucket.org/scons/scons/wiki/ToolsInde
x).
Or if you like add it to here: https://bitbucket.org/scons/scons-cont
rib



This raises the issue of whether we should be thinking about active
curation of the Contrib repository, and how to manage it.

[...]

So this raises a number of issues.

1. What is the purpose, aim, and goal of the Contrib repository?


To collect Tools, Config and other snippets...as contributed by users.


2. Is it intended as the place where things will be migrated out of the
SCons core distribution?


No...in the sense that I don't know of any plans to migrate current core tools. It will be more like the place where Tools get ready 
to be migrated "into" the core, once they have proper tests and documentation. A replacement for all the Wiki snippets and, where 
the current maintainers want this, all the single ToolsIndex repos...



3. Should it deploy into the running SCons installation or to a
site_scons/site_tools?


Neither...my idea is that it installs "parallel" to an SCons distro, while SCons' Python search path is patched such that all 
modules in "scons-contrib" get found as if they would lie directly in the "scons" folder.
This might imply that "scons" and "scons-contrib" get released simultaneously, maybe even with the same version number...not sure 
about that yet, there definitely has to follow some discussion about this.



4. Is it just for tools?


No...anything that is useful and could be good to have for importing it into an 
SConstruct/SConscript is allowed and encouraged.


5. Should SCons support not-tool add-ins better?


I think that being able to directly import add-ins from the "contrib" repo 
without any further ado would qualify here, right? ;)


6. What is the process for adding things to Contrib?


Creating a pull request.


7. What is the mechanism for removing things from Contrib?


ditto ;)


8. Is it feasible to move the C, C++, Fortran, D stuff out of the core
without a total rewrite of the core?


Have we decided to do such a thing...and when exactly did that happen?


9. Is anyone thinking about how to do C++ builds with SCons in the
presence of package managers such as Conan.

In a sense I feel a bit of a fraud contributing here just now. Apart
from LaTeX builds, and a few small pet projects, I am hardly using
SCons just now.


Which makes your insights and opinions even more valuable, to me at least. :) Conan is a good example, never heard of it...until 
now. Good to have someone affiliated with the project who is able to track all the "rest of the Internet" for interesting tools and 
technologies. Please don't stop prodding us. :)


Best regards,

Dirk

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

Re: [Scons-dev] The Contrib Repository. [was Adding support for Visual Studio Code workspace generation]

[Dirk Bächle]

Andrew,

On 28.11.2016 23:29, Andrew Featherstone wrote:

On 28/11/16 21:09, Dirk Bächle wrote:


[...]


My plan was simply to put something alongside the existing tools in
src/engine/SCons/Tool/ . "community supported" is a bit of an odd thing
to me. Just developing in one place would be much simpler and feels a
lot more "community" rather than "Go in play in the sandbox, we might
integrate your work if you meet an undisclosed criteria.".



those criteria are well known...your Tool needs tests and documentation, then it can get integrated to the core directly. We won't 
change anything about this "barrier" soon...so if you'd rather skip the "sandbox" stage and invest some time in writing proper tests 
and such, be our guest. :)


Dirk

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

Re: [Scons-dev] Anyone heard of or using Cuppa?

[Dirk Bächle]

Hi there,

On 16.11.2016 16:07, Bill Deegan wrote:

Just got a query on the IRC channel and hadn't heard of it myself.

Interesting.
https://github.com/ja11sop/cuppa



, yes...I heard about it before (found it googling on youtube for "SCons" 
related stuff):

https://www.youtube.com/watch?v=h_HhBT6xGeE

Regards,

Dirk

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

[Scons-dev] Must...watch...Python

[Dirk Bächle]

Hi there,

the winter holidays are coming, with all its long evenings in front of a fireplace...or the internet. If you should ever get tired 
of "funny cats" videos or "React to" episodes, why not treat yourself to a heavy overdose of Python? ;)


Just found this repo, have a look:

https://github.com/s16h/py-must-watch

(or http://pymust.watch/).

Best regards,

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

Re: [Scons-dev] Why are Builders excluded from env.Clone()?

[Dirk Bächle]

Hi Jonathon,

On 09.12.2016 18:03, Jonathon Reinhart wrote:


[...]

This behavior does appear to be intentional, however:

builders = self._dict.get('BUILDERS', {})

clone = copy.copy(self)
# BUILDERS is not safe to do a simple copy
clone._dict = semi_deepcopy_dict(self._dict, ['BUILDERS'])
clone._dict['BUILDERS'] = BuilderDict(builders, clone)



please check issue #2821 (http://scons.tigris.org/issues/show_bug.cgi?id=2821) 
where the latest changes have been made in this area.


BUILDERS is explicitly excluded in the semi_deepcopy_dict() call.

My questions:
 - Why are Builders explicitly excluded from the env.Clone()?


Because it's possible that during the deep-copy, the original is altered too 
(see comment in BuilderDict::__semi_deepcopy__).


 - Would it be reasonable to add an optional argument to Clone()
   (e.g. really_deep) which causes Builders to not be excluded?



As the bug description reveals, no real cure has been found yet. If you have a solution that successfully deep-copies the BUILDERs 
dict, and is guaranteed to leave the original environment intact...we'd definitely be happy to hear about it.


Best regards,

Dirk

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

Re: [Scons-dev] D support, not sure what to do

[Dirk Bächle]

Hi Russel, hi Jean-Baptiste,


thanks a lot for starting and chiming in on this topic, which I think is 
an important one. When I read Russel's other (opinionated) post about 
how D is likely to gain more ground than Rust/Python in the future, I 
asked myself: What can we possibly do to support this? How can we be 
ready for this stream of development if it should really happen in, 
let's say, 2019?



So I'm all ears for trying to get better support for D into the SCons 
core. For me the main question, referring to your subject of "..., not 
sure what to do", is: What exactly would have to be done to make SCons 
the canonical choice as build system for D?



Can someone (we together) compile a list of things that would have to 
get implemented and improved? Something along the lines of:



- We need recursive Globbing. (Full support of Ant-like syntax)

- We need to be able to handle required Libraries as leaf nodes in the 
dependency tree, even if they reside in a remote repository/artifactory.


- We need to be able to cache the contents of those libraries locally 
(in case of being offline).




(I'd like to continue this list but my knowledge of D is obviously 
restricted...so feel free to add "- We need more SCons core devs to be 
proficient in D development." to the list above ;) )



Then we should have a look at this list, and decide which points are 
technically feasible and "in line" with SCons' basic design principles. 
We can probably also identify a number of features that are not only 
helpful for D...but other languages/toolchains as well. Those should get 
the highest priority perhaps...but I also believe that any kind of 
development in the core sources, even if strictly D-oriented, is good 
for the project.



Best regards,


Dirk


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

Re: [Scons-dev] SCons performance investigations

[Dirk Bächle]

On 24.07.2017 23:29, Bill Deegan wrote:
As Jason said, if you run a profile on a reasonable sized build the 
MD5'ing doesn't really show much % of runtime.




Unless your project is called "MongoDB". ;)

Dirk

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

Re: [Scons-dev] SCons performance investigations

[Dirk Bächle]

Hi there,


On 21.07.2017 17:39, Andrew C. Morrow wrote:


Hi scons-dev -

The following is a revised draft of an email that I had originally 
intended to send as a follow up to 
https://pairlist4.pair.net/pipermail/scons-users/2017-June/006018.html. 
Instead, Bill Deegan and I took some time to expand on my first draft 
and add some ideas about how to address some of th e issues. We hope 
to migrate this to the wiki, but wanted to share it here first for 
feedback.





and thanks to everyone who contributed to this interesting discussion so 
far. I'd like to chime in on the topic, but not by delving into 
"optimization"...you seem to have this working area covered nicely.


Instead I'm very much after somehow connecting all the important points 
that you brought up, with my own plans about the future of SCons' 
design. I've started to write down how I'd like the core sources to be 
more flexible, more lightweight and more eligible to things like 
subclassing and adding new classes or strategies.
What I'd like to propose as the overall strategy is, to not try and make 
the current "scons" executable to be more versatile. Here I mean 
"versatile" in the sense that it can be adapted to several different 
"build project scenarios", such that it will give the maximum of speed 
or safety in each case.
Rather I'd like to put this "versatility" into the SCons core and its 
classes. Strengthening the framework character of SCons again by 
allowing new frontends to be developed more easily.
One of these frontends could be a "scons-lite" (*) for "flat" and large 
C/C++ projects, where the main task is "compile classes into libs". By 
simply not supporting "override environments"


env.Library('foo', Glob('*.cpp'), CPPFLAGS=['-wall','-g'])

we wouldn't have to "subst" so much and build/update times would go down.

This approach would allow us to leave the current "scons" frontend as it 
is, instead of adding more and more features and command-line arguments 
to it. This feels just right to me...I probably can't exactly explain why.


Finally, one more comment regarding performance. It's tempting to try 
and reach the build and update times of other tools like "ninja" and 
"make", but it's also okay to not fully reach them. We don't have to 
hide with our project, especially once the "stubprocess" wrapper has 
been integrated.
After all, there is a very important (in my opinion) distinction to be 
made between SCons and other build tools like the autotools or CMake: 
the latter two, and a bunch of others, are "Makefile" generators. They 
allow you to (re)create a build description for your project, that will 
ensure correct builds as long as the dependencies don't change. But the 
decision about when you should rerun this generator step is left to the 
user, which is a disadvantage in my eyes.
Since SCons is reconsidering all dependencies for every build, it's 
natural that we spend some more time than a "brute-force make". I guess 
what I'm trying to say here is: let's not over-optimize and by that 
destroy the "beauty of SCons". ;)


So, once again, I'd like to join the party with my (crazy?) "design 
ideas". Does this sound interesting, and if yes, how do we organize 
things to further discuss this?



Best regards,

Dirk


(*) : Naming is hard... :P

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

Re: [Scons-dev] SCons, Mercurial, BitBucket, Git, and GitHub

[Dirk Bächle]

Hi Tim,


On 29.08.2017 17:02, Tim Jenness wrote:
If you can add labels during the import then you could conceivably add 
age-based labels such as “ancient”, “1year”, “2years” or whatever. 
Then you would be able to get some feel for which ones are the old 
ones that have been lingering. That combined with ordering by issue 
number should be enough.




this would probably help. But there are some more things to regard 
("problems"?) when migrating to Github. One additional drawback is that 
you can't directly attach files to an issue. I found some links today 
that may give more food for thought:




https://github.com/JamesMGreene/gc2gh-issue-migrator

https://groups.google.com/forum/#!topic/silverstripe-dev/MXBJoYUHTkg

https://stackoverflow.com/questions/7281304/migrate-bugzilla-issues-to-github-issue-tracker 



http://numpy-discussion.10968.n7.nabble.com/Migrating-issues-to-GitHub-td31124.html 




Overall I still see that we'd lose a lot of information and 
functionality, but if we come to the conclusion that we don't actually 
need those...it'll be fine with me. ;)
I just don't want people to scream "bloody murder" afterwards and having 
to do another migration to fix things. ;)


Best regards,

Dirk


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

Re: [Scons-dev] SCons moves to GitHub! https://github.com/SConsProject/scons

[Dirk Bächle]

Anatoly,


this isn't quite correct. The figures you show here are for

- removing the docbook folder, AND

- compressing the repository.

Your pastebin shows that you don't run a compression *before* removing 
docbook. If I do a fresh checkout:


git clone https://github.com/SConsProject/scons

and then a

git reflog expire --expire=now --all && git gc --prune=now --aggressive

I get

git count-objects -vH

...

size-pack: 12.26 MiB

So, compressing the repo is a good idea in general, and I'm totally for 
it. But removing docbook (which isn't easily possible anyway because our 
doc toolchain relies on it currently) would save us only 2MB roughly.


Regards,


Dirk


On 24.09.2017 10:50, anatoly techtonik wrote:

Just removing docbook-xsl-1.76.1 brings compressed repository
size from 110.50 MiB down to 10.45 MiB

https://pastebin.mozilla.org/9068127

On Sun, Sep 24, 2017 at 10:50 AM, anatoly techtonik  wrote:

HI Bill.

History is ok, but repository size is now too big.

 Receiving objects: 100% (51561/51561), 109.12 MiB | 1.08 MiB/s, done.

We should take the opportunity to clean up binaries
and huge commits made by mistake. I am trying to
see what are they.



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

Re: [Scons-dev] SCons, Mercurial, BitBucket, Git, and GitHub

[Dirk Bächle]

Hi Russel,


On 28.08.2017 09:43, Russel Winder wrote:

[...]


The question then has to be how to bring the issues from Tigris to
GitHub. GitHub issues has an API. If Tigris Issues also has an API then
it is a question of writing a program, I guess in Python3, since that
is likely easier than trying to find tools to do the job. For me, there
is no point in leaving the issues at Tigris. No matter how much better
the interface is perceived to be compared to GitHub issues, to get the
integrated workflow of GitHub, it is essential to have the issues on
GitHub.



not so quick young grasshopper. ;)  (Sorry, I couldn't resist)

I already have a working and complete scraper for the Tigris bugtracker. 
It's written in Python2 though, but this wouldn't really be a 
showstopper, would it?
I contributed the code in a slightly changed form to the OpenHatch 
project, but it's also available in a stand-alone form. It downloads all 
issues, together with their notes and attachments into XML files. There 
exist also "wrapper" classes for accessing single issues and messages.


It may be true that Github has an API for entering bugs, so a migration 
looks like it's a "piece of cake". But be warned that there is caveat in 
the form of the "creation date" of single issues. As far as I know, and 
the last time I looked, there is no API method to set the creation date 
of an issue.
The OpenHatch project itself learned this the hard way when they 
migrated their issue database to Github. Suddenly all issues would have 
the same creation date. There was no chance to distinguish between old 
and new issues (something that I would still like to be able to) and a 
lot of tears were cried.


A while ago someone showed up on the dev mailing list, being interested 
in migrating our issue tracker to Jira. I gave him my scraper sources, 
mentioned the "creation date" problem...and then never heard about this 
project again.


Finally and trying to not sound like a broken record, I also do have an 
almost complete migration to the Roundup bug tracker. We've demonstrated 
in a live instance that the basic migration works and all data is kept. 
That's where the work stopped, because I'm still waiting for a "go/no 
go" decision to migrate to a separate Roundup tracker instance. This 
hasn't happened yet...and I don't say this all while holding grief over 
the whole issue. I'm simply reporting what the status of work on this 
topic is, or better: was when I left it.


How to continue from here is definitely worth a discussion.

Best regards,

Dirk

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

Re: [Scons-dev] **JUNK** Re: SCons, Mercurial, BitBucket, Git, and GitHub

[Dirk Bächle]

Hi all,


On 31.08.2017 08:27, Dirk Bächle wrote:


Bill,


[...]



True. This can also happen after the initial migration.
Dirk - is it simple to grab the various attachments from tigris?


I'd say so, yes. Let me dig up the sources for that, which might take 
a day or two.




please find attached a recent version of my migration script 
"Tigris->Roundup". Follow the comments inside to download all current 
issues (including attachments). Then you'll be mostly interested in 
"create_file", it's currently using xmlrpclib to write to a Roundup 
tracker instance directly. But hooking your own code in for pushing to 
Github shouldn't take that much work. ;)


Best of luck, and have fun!

Dirk


""" Import tracker data from Tigris.org

This script needs the following steps to work:

1. Extract the issues as XML files via the project's xml.cgi:

import_tigris.py files  

   this will place all the downloaded XML files in the files dir.
   An example:

import_tigris.py files scons import

2. Import the data via xmlrpc:

import_tigris.py push  

   Example:

import_tigris.py push http://admin:admin@localhost:8917/demo/xmlrpc import

And you're done!
"""

import sys
import os
import glob
import lxml
import lxml.etree
from urllib2 import urlopen
import base64
import xmlrpclib
import csv

# -
# natsort: Natural string sorting.
# -

# By Seo Sanghyeon.  Some changes by Connelly Barnes.

def try_int(s):
"Convert to integer if possible."
try: return int(s)
except: return s


def natsort_key(s):
"Used internally to get a tuple by which s is sorted."
import re
return map(try_int, re.findall(r'(\d+|\D+)', s))


def natcmp(a, b):
"Natural string comparison, case sensitive."
return cmp(natsort_key(a), natsort_key(b))


def natcasecmp(a, b):
"Natural string comparison, ignores case."
return natcmp(a.lower(), b.lower())


def natsort(seq, cmp=natcmp):
"In-place natural string sort."
seq.sort(cmp)


def natsorted(seq, cmp=natcmp):
"Returns a copy of seq, sorted by natural string sort."
import copy
temp = copy.copy(seq)
natsort(temp, cmp)
return temp

# -
# Download issues from Tigris
# -


def issue_exists(id, url):
""" Return whether the issue page with the given
index (1-based!) exists, or not.
@param id Index (1-based) of the issue to test
@param url Base URL to the project's xml.cgi (no params attached!)
@return `True` if the issue exists, `False` if not
"""
query_url = url + '?include_attachments=false=%d' % id
try:
issues_xml = lxml.etree.XML(urlopen(query_url).read())
for issue in issues_xml.xpath('issue'):
error = issue.attrib.get('status_code', None)
if error and error == "404":
return False
else:
return True
except:
pass

return False


def binprobe(left, right, index_exists):
""" Searches the last existing entry in a
"sequence of indices" from left to right (including).
Assumes that "left" starts on an existing entry,
and left <= right, and left >= 0, and right >= 0.
The index "right" may either be the last existing entry,
or points to an entry that doesn't exist.
@param left Start index
@param right End index
@param index_exists Function that checks whether a 1-based index
 is in or out of the sequence (exists or not).
@return 1-based index of the last existing entry, in
 the given interval
"""
while ((right - left) > 1):
middle = left + (right - left) // 2
if not index_exists(middle):
right = middle - 1
else:
left = middle

# Special handling for when only the two
# last IDs are left...or a single one (left=right).
if index_exists(right):
return right
return left


def get_number_of_issues(url, start_id=1, BSEARCH_STEP_SIZE=1024):
""" Return the 1-based index of the highest available (=existing)
issue for the given base URL, when starting to
probe at start_id.
@param url Base URL to the project's xml.cgi (no params attached!)
@param start_id Index (1-based) from where to probe upwards
@return 1-based index of the last existing issue
"""
# Start at the given index
id = start_id
# Loop in large steps, until id doesn't exist
steps = 0
while issue_exists

Re: [Scons-dev] SCons, Mercurial, BitBucket, Git, and GitHub

[Dirk Bächle]

Bill,


On 29.08.2017 22:14, Bill Deegan wrote:

Dirk,

Does the script migrate attachments?



yes, it also downloads all attachments. But, as mentioned in my other 
post, you can't upload them directly to Github. :(
And we might create the issues one-by-one in their natural order as you 
suggested, such that the Tigris IDs are kept. But in the normal view 
under Github you can't even see this ID. :(


Regards,

Dirk

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

Re: [Scons-dev] **JUNK** Re: SCons, Mercurial, BitBucket, Git, and GitHub

[Dirk Bächle]

Bill,


On 31.08.2017 02:46, Bill Deegan wrote:



On Wed, Aug 30, 2017 at 9:55 AM, Gaurav Juvekar 
> wrote:


Hi,

[...]

Couldn't the patches be re-uploaded as gists and then linked from
within the
GitHub issue?


True. This can also happen after the initial migration.
Dirk - is it simple to grab the various attachments from tigris?


I'd say so, yes. Let me dig up the sources for that, which might take a 
day or two.


What I also have is a complete download of the old "devel" and "user" 
mailing lists from Tigris. My goal for these is to write some data 
classes that enable you to search for certain keywords over the single 
entries. Like this it could serve as some kind of "knowledge base".
Together with the snapshot of the "issues", we could add them to a 
separate "scons-archive" such that no information gets lost.
The remaining task would then be to make this "info heap" searchable in 
some way.


Regarding size, we are talking about approximately:

issues : 53 MB (without attachments)
devel : 164 MB
user : 244 MB

Best regards,

Dirk

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

Re: [Scons-dev] should src/engine/SCons/Tool/docbook/util/* be included in the packages?

[Dirk Bächle]

Hi Bill,


Am 07.10.2018 um 21:44 schrieb Bill Deegan:
Are the docbook xslt stylesheets we're currently including reasonably 
available from distro's repos?




I haven't checked yet, but my guess is that some version would be 
offered in the major distros. But the problem is then that different 
naming schemes would be used and the folder with the stylesheets would 
be stored in random locations. This makes it difficult to provide an 
out-of-the-box experience with the Docbook Tool.



I saw today that the actual sources of the Docbook XSLT stylesheets are 
now hosted on github too! This made me think: Maybe it would be okay to 
add another "bootstrapping step" to the Docbook Tool, where it clones 
the stylesheets from github to its local folder?


Then we wouldn't have to store all the XSLT files directly in our repo. 
Our build/release workflow would get a little more complicated and users 
of the Docbook Tool would have to "init" it once on each of their 
machines. But maybe it's worth giving it a try?


I could work on a new version of the Docbook Tool that would support 
this, if we agree that's the way to go.



Best regards,


Dirk



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

Re: [Scons-dev] should src/engine/SCons/Tool/docbook/util/* be included in the packages?

[Dirk Bächle]

Hi there,

and sorry for the late answer...

On 06.10.2018 06:26, Bill Deegan wrote:
Strange that it's referring to "/usr/lib/scons/SCons/Tool/docbook/utils/xmldepend.xsl",  it should be referring to build/... for the 
unpacked version of the package.


Have you run python bootstrap.py first?

On Fri, Oct 5, 2018 at 1:35 PM Paweł Tomulik mailto:ptomu...@meil.pw.edu.pl>> wrote:

The problem still persists:

I/O warning : failed to load external entity
"/usr/lib/scons/SCons/Tool/docbook/utils/xmldepend.xsl"
scons: *** [build/doc/user/manual.fo ] parserError : 
xmlParseFile() failed
scons: building terminated because of errors.

should I file an issue on GitHub?



I think that xmldepend.xsl should be contained in the packages. I checked back to SCons v2.3.2 and it was never included right from 
the start. Funny that nobody noticed until now, I guess I always tried to rebuild from the sources on my machine...definitely have 
to amend my workflow for preparing release packages. ;)


Pawel, please open an issue on github about this, I'll try to look into it as 
soon as possible.

We should also discuss what to do about the copy of the docbook XSLT stylesheets that are checked in alongside with the sources. 
Should these be packaged too, such that the user doesn't have to care about installing them separately?


Best regards,

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

Re: [Scons-dev] bug prune

[Dirk Bächle]

Hi,

this approach sounds good to me too. I just wanted to mention that I have all 
the old Tigris Issues (and user and developer mails)
archived on my local machine. They're stored in a simple text-ish format that 
can be read into corresponding Python classes.
My plan is still to write a small "viewer" app, that would enable interested developers/users 
to "browse" through the "SCons
archives". In my view there is a lot of hidden knowledge in there, that we 
can't really use at the moment.

I'll try to check whether my "archive" is still up-to-date during the next 
days. ;)

Best regards,

Dirk

On 27.08.19 15:53, Gary Oberbrunner wrote:

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 mailto:m...@wichmann.us>> 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=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



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

Re: [Scons-dev] scons: path-like objects

[Dirk Bächle]

Hi Mats,

On 04.09.19 19:29, Mats Wichmann wrote:


does anyone think it is important to examine scons for support of Python
path-like objects?



I think this is important enough to put some research effort in it. But only if 
we're talking about the FS-centric Node classes
"Node.FS.Base" and its derivants.
From an architectural point of view I still see SCons as a "build framework". 
At the moment we're mainly supporting files and
folders as Nodes, but I'd like to have enough flexibility to also support e.g. 
"database Nodes", if required.


Best regards,

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

Re: [Scons-dev] adding qt4/qt5 to scons-contrib?

[Dirk Bächle]

Hi Mats,

I'm basically fine with this. Some while ago the idea was even to integrate the 
qt4/qt5 Tools to the scons-core directly...this
would work for me, too.

If you need additional support from my side, please let me know.

Best regards,

Dirk

On 17.05.21 19:09, Mats Wichmann wrote:


Just checking if it's okay to pull in the qt4 and qt5 repositories to
https://github.com/SCons/scons-contrib?

Dirk, you currently have these two in your github account, and they're
linked off the wiki page.

Since the qt tool in SCons is useless (qt3 has been essentially obsolete
for 15+ years and Ubuntu versions long since stopped even providing a
runtime, though I suppose an intrepid developer could build their own
from sources if compilers haven't gotten fussy enough that they'd
refuse) - I wanted to add a note to the docs, but I'd rather add one
pointing to scons-contrib than one pointing to a wiki page.

Guess we need a qt6 now :)  though there seems to be effectively no demand.

regards,

-- mats

___
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