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

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] 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] 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] 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] **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] **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] 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] 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, 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] 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 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] 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] 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

[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] 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] 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] 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] 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] 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] 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]

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] 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] 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] 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

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] 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,

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] 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] 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] 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] 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

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

[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] no more print statements in SConscripts?

[Dirk Bächle]

Hi there,

On 26.05.2016 03:52, Jason Kenny wrote:

I am unclear on what people are suggesting as fixes to the issue. However I 
believe we tweak the way we “load” the Sconstruct we can
control which print logic is used when python 2.7 is used. I don’t believe 
there is any way to allow the “classic” python 2.7 print
to work in python 3.

I think if we can allow user of python 2 and SCons to not have their files 
break, that is a win. When using python 3 the users will
need to update the SConstruct print statements ( or use some API we might be 
able to add).


it just came to my mind that we also have to think a little about the external tools. They need to get updated too...which is 
actually more of a task for each repo owner, but it would be good to have some kind of support here.


Regards,

Dirk

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

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

[Dirk Bächle]

Hi Gary,

On 25.05.2016 14:59, Gary Oberbrunner wrote:

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

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



we'd probably have to advise them to use a conversion script like "2to3" on all their SConstructs, right? I'd think this is not too 
much to ask for, if people are really interested in using the Python3 version of SCons...


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] 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] 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 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] 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] 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] Trial SCons migration to git on github

[Dirk Bächle]

Hi,

On 06.01.2016 22:16, Jason Kenny wrote:

I have done the opposite myself ( moved code from guthub to bitbucket) it is 
very easy either direction.

However I have to ask. Is this about moving to Git from HG or to Github?
I think these are two different questions.



I would also like to make us a clear statement first, about what we want to change/migrate and why we want to do it. I'm currently 
trying to find examples of large open-source projects (not some small repos, maintained by a single person) that have moved from 
Mercurial to git. Can anyone give pointers?
My goal here is to analyze the log/commit history in order to find out whether the migration actually did have a measurable effect 
on things like "frequency of commits per month", "LOC touched per month", "new committers per month" and so on.


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 Sanjeev,

On 03.01.2016 17:22, Sanjeev Gupta wrote:

Hi,

I know of scons through the gpsd project.

Would you be interested in an ubuntu-next buildbot?  I run some servers and 
desktops updating daily from 16.04-proposed.  This might
be of interest because you will be able to see issues that may surface a few 
months ahead.



thanks a lot for your kind offer, and we're definitely interested. Setting up a 
Buildbot slave isn't that complicated and you can
find instructions describing the basic steps in our Wiki at

   https://bitbucket.org/scons/scons/wiki/InstallingBuildbotSlaves

Administering it yourself shouldn't be too hard, it's running automatically 
after the basic setup.

You also need a login and password, such that your slave can connect to the 
server machine and register itself as being available.
Bill Deegan is maintaining the server and can provide you with the credentials, I guess. Please check the list of installation steps 
above, and confirm that you feel able to setup a slave...then we can take it from there.


Best regards,

Dirk

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

Re: [Scons-dev] Rumour…

[Dirk Bächle]

Hi there,

On 05.01.2016 18:25, Bill Deegan wrote:

Not a rumor. ;)
http://lwn.net/Articles/669924/

http://thread.gmane.org/gmane.comp.python.devel/150459/focus=150960




when I read those two threads/articles it doesn't seem to be about "moving Python to Github"...they're considering (PEP481) to 
migrate certain supporting repositories, that don't need a bug tracker and can be used as a stand-alone repo.

Am I getting this right?

If yes, this is a different situation than we would have...we still have a bug tracker to migrate. And so far, everybody who tried 
to come up with a proposal about how to do it, while losing no significant data, seems to have given up on it. Would this change if 
we move to Github?


It may be true that a lot of people nowadays simply know how to use "git" (or maybe they only "think" that they know ;) ), but I 
can't see a big boost of new contributors growing from this fact alone. OpenHatch has moved to Github recently (including their bug 
tracker) and they're still struggling and desperately calling for help. Maybe it is the "wrong" example, but it doesn't seem to be 
*that* easy. And someone has to do the migration work...I'd like to see volunteers and their ideas for the migration first, before 
supporting this idea.


I'm not completely opposed to the idea of moving to Github ( and git, which I also know a bit, at least I "think" I do ;) ), but 
deep in my heart I still very much feel like Nick Coghlan (see http://thread.gmane.org/gmane.comp.python.devel/150459/focus=150960 ) 
and think about Mercurial and SCons as part of the Python family. This weighs a lot in my opinion, so you have to put much more than 
"convenience" and "I suspect"s on the other side of the scale to convince me. :)


So much for my 2c.

Best regards,

Dirk

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

Re: [Scons-dev] Code of conduct?

[Dirk Bächle]

Anatoly,

Am 28.12.2015 um 15:33 schrieb anatoly techtonik:

[...]

I'm not sure why you're objecting to this unless you think you are likely to
violate a CoC..

Because following CoC makes people CoC-followers, which is offensive for
some. Don't be a jerk rule is good enough and the rules should be applied
only when they are needed on personal basis.

I am against CoCs. It makes me feel regulated and I am sick and tired of that,
so I likely to act against it and you have to ban me.
feel free to "act against it", but "filibustering" (refer to 
http://www.merriam-webster.com/dictionary/filibuster and optionally 
https://www.youtube.com/watch?v=Q52kFL8zVoM ) won't help. We've already 
reached consensus to have a simple CoC and are simply ironing out the 
last details.


@all: Are we ready to move on with this one and take some action? I am...

Best regards,

Dirk

P.S.: Nobody wants to ban you. We'll simply continue with our plan and 
are ready to face the consequences of you getting "sick and tired" about 
feeling regulated again...


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

Re: [Scons-dev] New SCons website

[Dirk Bächle]

Hi Bill,

On 27.12.2015 23:30, Bill Deegan wrote:

All,

I've made a few more changes.
Thoughts?

http://scons.org/new/



this looks just great to me. I like it a lot, especially compared to the 
old design. ;)


One more suggestion (since you asked for it): Can we add a short 
paragraph at the bottom of the starting page, with a heading like "Where 
do I go from here?" or "How should I start?". It could list some of the 
links in the menus above, but embed them in free text:


How do I start using SCons?
===

Please  and install it as described in . 
You should then be able to call the "scons" command in a terminal of 
your choice. Start reading the  and try out some of the 
examples in the first chapters, just to get a feel for the way SCons 
handles build processes. For the more technical questions, you can 
either refer to our rather extensive  ("man scons" under 
posix-like systems), or ask questions on our .
We also have a  with lots of  and other 
guidelines, e.g. about how to  or how to 
.





Best regards,

Dirk

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

Re: [Scons-dev] Updating roadmap in wiki

[Dirk Bächle]

Hi,

On 27.12.2015 21:49, Bill Deegan wrote:

Greetings,

I"m doing some updates on the roadmap.
Are there any missing items?
Any items listed which are already completed?



just want to raise attention to the following two pending items (again):

- Legal status of SCons foundation (putting it under the umbrella of 
what-was-it-called-again?)
- Already on the roadmap, but still to discuss how to proceed exactly: 
Migration of the bugtracker (away from tigris.org) is at a stall 
currently. The Jira tryout seems to be stuck, or at least the current 
status is unclear. I can do a recap of my work for Roundup, but will 
invest further time in this only if we agree that this is the way to go 
(at least for a first migration).


Regards,

Dirk

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

Re: [Scons-dev] Issue 2494

[Dirk Bächle]

Hi Adarsh,

and thanks for wanting to help out!

On 28.12.2015 13:42, Adarsh Sanjeev wrote:

Dear developers,

I am interested in taking Issue#2494 and am a beginner in contributing 
to open source. I do not have any experience in doing so. Please 
advise me on how to proceed.




Your first step should be to check out our landing page

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

, which is especially written for new developers like you. It contains a 
lot of pointers to more material and our basic workflows. Please try to 
give it a thorough read (this might take a while ;) ), then just try to 
start...and come back with more specific questions (preferably to the 
scons-users mailing list first).
Since you mentioned that you're completely new to open-source 
development, make sure that you watch Julie Pichon's talk, you can find 
the link on the webpage mentioned above.


Best regards, and welcome to the project,

Dirk

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

Re: [Scons-dev] stubprocess ?

[Dirk Bächle]

Hi Vasily,

On 23.12.2015 22:04, Vasily wrote:

Hi Bill and all,
Since we (Eugene - added, and me) were original authors, maybe we should work 
on making a pull request.
Can you share the requirements for successful pull request?

P.S. I think that making an env opt-out key is hard to do since it 
monkey-patches subprocess module globally, but making an
command-line option might be a good idea.



thanks for offering your help with this. I agree that we shouldn't care about an option for switching the stubprocess wrapper off. 
As far as I remember we discussed this some time ago, and the consensus was to always activate the wrapper under "posix"-like systems.


One remark though: Can we possibly rename the patched subprocess call to a different module? For our purposes (in SCons) we don't 
need a global replacement, but just a method that we can stuff into our env["SPAWN"] variable which gets used for every command-line 
action that has to get executed.

What I have observed is, that the global replacement of "subprocess" gives 
trouble when custom Builders or SConscripts do an
"import subprocess" again afterwards. How do we protect against this? If possible I'd like to have the wrapper decoupled from the 
"subprocess" module...


For the pull request, please fork the current "trunk" from the main repo as 
described at

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

. The section "Fixing and developing the core sources" should get you going...if you have any questions, feel free to ask please. 
From my point of view, you won't have to provide any additional tests or documentation. We just have to ensure that all the current 
tests still work afterwards...and then there's one more detail: Licensing and copyrights. I'm not sure what the state of the 
stubprocess wrapper is, regarding copyright. I assume that it was (at least partly) developed during your work time for Intel, so we 
(SCons foundation) should get a document (email might be enough?, but I'm not a lawyer) allowing us to distribute the wrapper 
together with our sources, under the same MIT license (we'd mention Intel and your names in the copyright, can you make a proposal 
for the exact text?). I'd really like to have this in writing somehow...


That's what I can think of for the moment...happy hackin'! ;)

Best regards,

Dirk

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

[Scons-dev] A new architecture...

[Dirk Bächle]

Hi all,

the discussions about new features in SCons during the last weeks, have led me 
to start working on some architectural changes
for SCons. They aim at refactoring the module/package structure, such that it's 
possible to better support customized

- Taskmasters
- File signature calculation (currently fixed to MD5 hash sums)
- Node factories (and connected with that custom Nodes)
- Build and Node Info (and connected with that custom signature DBs, like a 
JSON implementation for easier debugging)

.
Please note that my pull request doesn't directly implement and provide these functionalities (well, some of it), but simply tries 
to lay out the foundation for them. There is definitely more work ahead...

Once we have this in place, it should be much easier to support e.g. additional 
Taskmasters like an

  EspeciallyParanoidTaskmaster

(see Tom Tanner's proposal at 
https://pairlist4.pair.net/pipermail/scons-users/2015-December/004320.html and 
following), or a

  DebuggingTaskmaster

where you get a lot of additional info about the current "machine state", and 
can walk through a complete build in single steps.

I don't know when this PR will be ready, but just wanted to inform you all that 
someone is working on this somewhere. :)
Your comments and suggestions are welcome.


Best regards,

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

Re: [Scons-dev] Huge merges in Mercurial

[Dirk Bächle]

Russel,

On 19.12.2015 14:31, Russel Winder wrote:

Hi,

I tried an experimental merge and much of the stuff looks like it will
go straight through. However there is a lot of 3-way meld resolution to
be done, hours of it, possibly days. Clearly there is no problem the
human taking breaks as long as the computer doesn't. But what if…

Has anyone any experience of checkpointing and restarting big Mercurial
merge resolutions?



not with Mercurial so far, but here's what I tend to do at work (Clearcase) 
when things get complicated:

For every conflicting file I'll accept the "new" changes completely, overwriting old stuff. This is just to get the basic "merge" 
operation through.
Afterwards, I look at the single "diffs" and do the actual merge work by trying to amend those places where some of the "old" stuff 
is still needed.

Note how you can list the "to be resolved" files with

  hg resolve -la

Hope this helps you further, you may want to combine the "amend" work with 
using the MQ extension...

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 all,

On 15.12.2015 23:07, Bill Deegan wrote:

Dirk,

Looks like the pull request blew up windows testing..

http://buildbot.scons.org/builders/win7-64-vs20102.7/builds/257/steps/shell/logs/stdio



I fixed the problem directly on the trunk. Buildbots are still running, but it 
looks much better now.

@Russel: If all Buildbots turn out to be "green", feel free to merge onto the 
python3 branch...

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]

Bill,

On 15.12.2015 23:07, Bill Deegan wrote:

Dirk,

Looks like the pull request blew up windows testing..

http://buildbot.scons.org/builders/win7-64-vs20102.7/builds/257/steps/shell/logs/stdio



sorry for that.


Do you have access to a machine to take a look?



I'd have to fire up one of my old Windows XP boxes under kvm/VirtualBox and see if I can reproduce the error...not sure if this is a 
good idea though, because it would only have MinGW installed...but no VisualStudio of any kind. And I'm not sure that I have a 
decent Python 2.7.x in there, might be only 2.6, arrghh. I would also get to this tomorrow night earliest, it's pretty late here 
already.


So if you can take a look, I don't mind you (or someone else) taking over... ;)

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]

Bill,

On 15.12.2015 23:07, Bill Deegan wrote:

Dirk,

Looks like the pull request blew up windows testing..

http://buildbot.scons.org/builders/win7-64-vs20102.7/builds/257/steps/shell/logs/stdio

Do you have access to a machine to take a look?



just gave this another short look, and I think I know what's wrong:

src/engine/SCons/Util.py, make ll. 587 look like this


if can_read_reg:
WinError = WindowsError
HKEY_CLASSES_ROOT  = hkey_mod.HKEY_CLASSES_ROOT


such that Util.WinError gets also initialized if we can read the registry. That 
should help. ;)

Regards,

Dirk

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

Re: [Scons-dev] Code of conduct?

[Dirk Bächle]

On 08.12.2015 20:01, anatoly techtonik wrote:

On Tue, Dec 8, 2015 at 4:33 AM, Dirk Bächle <tshor...@gmx.de> wrote:

As Bill reported, people start to ask for a CoC when looking at a project.


What are their motivations?
1. "I am acting according to rules. I want to know if your rules match
those that I am acting."
2. "I am too vulnerable. I want to check if you will punish people who
will offend me."
3. ?



My guess would be that their motivations are as diverse as the people (and their backgrounds) which we try to reach with a CoC. I 
don't see a simple black-white scheme here...


Dirk

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

Re: [Scons-dev] Code of conduct?

[Dirk Bächle]

On 08.12.2015 22:36, Gary Oberbrunner wrote:

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



+1,

Dirk

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

Re: [Scons-dev] Code of conduct?

[Dirk Bächle]

Hi all,

On 04.12.2015 18:10, Bill Deegan wrote:

All,

Perhaps it's a good idea to add an official code of conduct for SCons.
http://blog.codinghorror.com/the-hugging-will-continue-until-morale-improves/

The following site seems to provide a reasonable code.
http://contributor-covenant.org/

Thoughts?



here's my opinion:

- +1, in general. I don't mind having a CoC, and I fail to see how following this "mainstream" (allegedly) pattern could harm the 
project.
- For my personal taste, the yahoo example provided by Gary is too long to read. Bill's and Russel's texts are shorter, and easier 
to digest for me as non-native speaker.
- Simply adopting one of those options would be fine with me. @WBlevins: I would be opposed to the idea of then adding more 
regulations on top. It's not much more than a badge, that says: "We care." And when the time comes, we'll take actions and "care" 
without having to look up our CoC. We've done this successfully in the past...


Best regards,

Dirk

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

Re: [Scons-dev] Code of conduct?

[Dirk Bächle]

On 07.12.2015 21:35, Alexandre Feblot wrote:

Hi,
Call me the Grinch, but I have the feeling there are 2 kinds of people in the 
world:
* those who behave naturally, who don't need such written CoC because it is 
obvious for them,
* those who would need it but definitely won't read and consider it because 
they think others are stupid / here to serve them / you
name it...

Am I already too desperate about people? :-)


Realistic, Alexandre...you're simply realistic. ;)

But as long as the people from group #1 agree on how to treat misbehaving people (as a subset of group #2) and don't let them be an 
impediment to the progress of the project (and I'm not only talking about source code here) we should still be fine...


Regards,

Dirk

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

Re: [Scons-dev] [Scons-users] Would requiring Python 2.7.4 or above be a problem for future release?

[Dirk Bächle]

On 25.11.2015 22:06, Russel Winder wrote:

On Wed, 2015-11-25 at 11:36 +0300, anatoly techtonik wrote:

My opinion that Python 3 is a trap. Before going this way and
breaking
stuff, just
try to port anything to this language to see for yourself. Mercurial
is still Python 2
and many other tools.



Python 3 is the future not a trap.


Sorry, I can't resist...quoting time!

Ackbar: "It's a trap!"
Dude: "That's your opinion, man."

Dirk

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

Re: [Scons-dev] SCons on pypy and slots and __class__ assignment

[Dirk Bächle]

Bill,

On 15.11.2015 23:36, Bill Deegan wrote:

Greetings,

Thought I'd take a whack at running SCons on pypy (based on a presentation at 
SFPython where the developer say 50x CPython speeds).

Anyway it turns out that using __slots__ + assiging to __class__ which we do a 
few places in the Node's classes causes:
TypeError: __class__ assignment: 'Entry' object layout differs from 'Dir':

I hopped on #pypy and a developer there took a quick look as said turning of 
__slot__ got it a bit further through.

As a side note, the canonical way to tell if you are running under pypy is as 
follows:

  if '__pypy__' not in sys.builtin_module_names

Anyone have any thoughts on the relative difficulties of disabling slots for 
pypy vs removing reassigning an objects class in the
Nodes hierarchy?



since you're only interested in the possible speedup of pypy vs. cpython, wouldn't it be an option to use a commit short before the 
introduction of "__slots__" and apply the PR #252 there in a sandbox?

Then you could first check whether following this route, and fixing things for 
the __class__ assignments, would be worthwhile...

Best regards,

Dirk

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

Re: [Scons-dev] A few tests failing with 2.4.1 package.. Doc issues

[Dirk Bächle]

Bill,

On 09.11.2015 15:45, Bill Deegan wrote:

Dirk,

Yes switched to a VM running Ubuntu 14.04.3 LTS.

I made that change and I still get a failure.



something's not right here. The log snippet still shows the old (incorrect) 
order of arguments. Can you check again?


See:
https://bitbucket.org/snippets/bdbaddog/X8k98

Looks like the xsl file and others aren't being copied into the Tool/docbook/ 
dir. No utils dir.



Let's fix the problem above first.

Regards,

Dirk


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

Re: [Scons-dev] A few tests failing with 2.4.1 package.. Doc issues

[Dirk Bächle]

Hi Bill,

On 09.11.2015 05:27, Bill Deegan wrote:

Dirk or someone who is more familiar with the doc toolchain,

Can you take a look:
https://bitbucket.org/snippets/bdbaddog/X8k98



looks like you now suddenly have a new system with "saxon-xslt"? I probably never got to actually test this command line program, 
because the order of the arguments is wrong. Please check ll. 162 in "docbook/__init__.py, and change to something like:


'saxon-xslt' : '$DOCBOOK_XSLTPROC $DOCBOOK_XSLTPROCFLAGS -o 
$TARGET $SOURCE $DOCBOOK_XSL $DOCBOOK_XSLTPROCPARAMS',

Note how the source document now comes before the XML stylesheet.
Hope this fixes it.

Best regards,

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

Re: [Scons-dev] Release Schedule

[Dirk Bächle]

Hi,

On 04.11.2015 11:51, William Blevins wrote:

Do we have an idea for the release schedule of 2.4.1 and 2.5.0?

Looks like pull requests have stabilized and the pile is pretty empty.  Might 
be a good idea to cut 2.4.1.  If this isn't a terribly
unreasonable request, I would like to see 2.5.0 released with cross language by 
mid-late December because if there are issues, I
might have time to look at them over my course break; otherwise, it will be 
much harder to find the time.



I still have the refactoring of the core on my list (throwing all the stuff Python < 2.6 out), not sure when I get to this however. 
Might happen next week...I'm keeping my fingers crossed. ;)


Best regards,

Dirk

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

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

[Dirk Bächle]

Hi all,

On 28.09.2015 14:42, Russel Winder wrote:

On Sun, 2015-09-27 at 15:03 -0700, Bill Deegan wrote:

Maybe worth sticking in a scons bitbucket repo?


[…]

A DVCS repository is indeed where all code belongs :-)



the basic part of the import routines is already under DVCS at the oh-bugimporter repo for openhatch.org (see 
https://github.com/openhatch/oh-bugimporters/blob/master/bugimporters/tigris.py ).
My idea was to work on this Tigris->Roundup script some more, and then offer it to the Roundup community since we'll use it just 
once anyway. ;)


However it seems that the majority is in favour of Jira, which is basically fine with me...but I'll put the converter script at the 
bottom of my TODO stack and see what Florian (or someone else) comes up with.


Best regards,

Dirk


P.S.: I'll shut down the Roundup demo instance now, I got the impression that most people had a short look at it...which was the 
main intention. Thanks to everyone who seized the opportunity and commented on it.


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

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

[Dirk Bächle]

Hi Florian,

as promised, here's a copy of the converter script in its current state and a 
short description of the whole conversion process.

Have fun with it! ;)

Dirk

On 25.09.2015 10:55, Florian Miedniak wrote:

Dirk, a copy of the script would be nice, so I could have a very first try, if 
a migration would be possible in general.

-Florian

2015-09-25 10:47 GMT+02:00 Dirk Baechle >:

Florian,

thanks for the additional info about Jira license fees.
My converter script pulls the issues from Tigris to a folder in XML format. 
From there, they get pushed into Roundup via its RPC
interface. So you'd have to care only about the second part only.
If you're interested, I can send you a copy of the script.

Best regards,

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(id, url):
id += BSEARCH_STEP_SIZE
steps += 1

if steps:
# Start the binary search
left = id - 

Re: [Scons-dev] SCons.. the road ahead

[Dirk Bächle]

Hi there,

On 26.09.2015 00:56, Bill Deegan wrote:

I guess the question is should that happen in 3.0 branch or default.
Since most likely it's in the core and not in the tools, I'm guessing 
none of the outstanding pull requests will touch that..




I'd like to try and remove some of the "< 2.6" stuff soon on 
"default"...even before the next SCons release. Refactoring the 2.6 
constructs that were added for backward compatibility, instead of using 
more modern idioms from 2.7.x/3.y, can then happen on the "python3" branch.


I'm basically fine with the short-term roadmap as suggested by Bill. But 
I'd like to stay on the "python3" branch for developing the combined 
2.7.x/3.y version. Let's merge "default" onto "python3" initially, and 
not the other way around. Like this, we're still able to make an 
immediate bugfix and push out a new release, if this should ever be needed.


Best regards,

Dirk


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

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

[Dirk Bächle]

On 24.09.2015 20:01, William Blevins wrote:

I took a quick peek.  Couldn't log in with demo/demo.  I got an invalid page 
address error.



Hmm, don't know...this is new to me. It worked when I tested it from "localhost", I guess that's the difference. Can't do much about 
it right now, due to a lack of time.

So everybody can only "look", I'm sorry about this inconvenience.


What advantage will this give us over tigris?  I realize it's a demo, but the 
example seems rather basic.


Where "basic" refers to? Design? Functionality?

Dirk


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

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

[Dirk Bächle]

Hi there,

I have imported the current bugs from our Tigris bug tracker (as of 2015-09-22) into a Roundup demo instance. It's running on one of 
my machines behind a DSL router, and will be available over the weekend at:


  http://dirkbaechle.dyndns.org:8917/demo/

Please take into account that my internet connection is not the fastest, so be 
patient. ;)

I tried to come up with a basic, more SConsy, design...sorry if it hurts your 
eyes.
Just use the chance to snoop around and get a first impression of what a 
Roundup tracker for SCons might look like.

TODOs so far:

- Switch to the "python-devel" template, such that we have some additional fields like 
"Dependencies".
- Come up with an idea about how to initialize the user's passwords (you can login as demo/demo, or as a existing user with an empty 
password, at the moment) and their EMail addresses.



Your comments and thoughts are welcome.

Best regards,

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

Re: [Scons-dev] SCons 2.4.0 Released

[Dirk Bächle]

Hi all,

On 23.09.2015 12:28, Russel Winder wrote:

On Tue, 2015-09-22 at 09:13 +0200, Dirk Bächle wrote:



[…]


I volunteer to weed out some of the old Python 2.x stuff (where x < 7
;) ) on a separate bug branch. I have all the scons_testsuite
stuff ready (just like for the slots change), in order to show that
there are no large speed penalties coming with it.



Does this mean we can revert all the 2.6-isms that were introduced
instead of using nice 2.7, 3.3+-isms?




I'd suggest to continue as follows:

  - Remove special Python constructs for Python 2.5 and smaller on a bug 
branch, then merge it
to tip of "default" as usual.
  - I'd then like to add another issue on top of this where I do some changes 
to the core architecture
(pushing classes around to entangle the dependencies of Node and Taskmaster 
a little bit), again
merged to "default".
  - Then, merge this new tip of "default" to the "python3" branch.
  - Continue with bugfixing on "default", while on "python3" we can then start 
to remove 2.6 constructs
and work on getting the code to be 2.7/3.x compatible at the same time.

Best regards,

Dirk

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

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

[Dirk Bächle]

Hi again,

On 23.09.2015 13:45, Russel Winder wrote:

On Wed, 2015-09-23 at 07:08 -0400, Gary Oberbrunner wrote:

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




here are my 2cents regarding changing our VCS or project hosting:

Let's. Not. Switch.

You ask why? Because I'm happy. I'm so happy that---after a seemingly never-ending series of events, with project managers leaving, 
switching from SVN to hg, migrating our Wiki to Bitbucket, and so on---we've finally reached a state where I can do what I like 
most: coding.


It's tempting to think: yeah, let's just import the current repo into git, push it to Github, and we're good to go again. But I 
count myself to be a member of the core developer team. So, in the case of switching to another VCS I'd feel obliged to work on 
setting up and properly documenting the new workflows in the Wiki. I'd also feel obliged to answer questions from newcomers, or 
people getting confused over the VCS change.

Which is both fine per se, but it would keep me from doing what I like most 
(and am good at, to a certain extent): coding.

But anybody out there has a good chance of convincing me that switching is good for the project overall, by (a priori to the actual 
switch) either:


  - providing a full replacement for the current descriptions of our general development workflow, and about howto creating pull 
requests in particular, for our Wiki and volunteering to answer all upcoming questions about it, or
  - jumping on a large bug or issue (like the python3 branch, for example), setting up his preferred git-hg bridge, working on 
stuff, and wowing me and everybody else with the way he makes impressive progress in a very short time. ;)



Which is sad because Git still has so much wrong with it, and Mercurial
has so much going for it. However, the social and commercial pressure
seems inexorable that Git shall be the monopoly.



I don't feel any pressure in this direction. (see also below)


I think there possible needs to be a new debate about whether to switch
to Git and GitHub.


I don't think so.

When the decision was made to move from Subversion

on Tigris to Mercurial on BitBucket, I had some issues/doubts, but the
final decision seemed fine and not a problem. However time has moved on
and we are are now in an era where to get any traction as a FOSS
project you appear to have to use GitHub.



Can you elaborate a bit on this conclusion? I fail to see the connection between "Project is at Github" and "Project is successful" 
as a direct consequence. How exactly do you get from one to the other?
Isn't it more the fact that, since a lot of projects are at Github (for whatever reasons), there's a high probability that a 
successful project is at Github? Have you checked for the opposite side of the scale? My bet would be that the worst doing projects 
are at Github too...because almost everybody is there!


I always thought that to get any traction and have success, you need to have a good product/project. Why don't we continue working 
on that in the first place?

We have a full roadmap and TODO list, and last time I checked there were 1500+ 
unresolved issues in our Tigris tracker. ;)


OK, I realize it is all "kool kids", "hipsters", and "people who say
awesome evey sentence", but the issue is not one of what is best as a
technology, it is what is best as a way of gaining traction.


See above for my notion of "traction". ;)

I

appreciate Mercurial is written in Python (mostly) and Python users
Mercurial, but they have PSF. SCons is just another ancient build
system trying to exist as a FOSS project.



This feels to me like we should accept getting dictated "from the outside" what to use in our project. I think that SCons as a 
(Python!) project has a good standing and can afford to "flex its muscles" when needed. You say that Mercurial gets left by many 
projects, and we should do the same? Then who's going to stay and ensure that Mercurial doesn't die (sorry, couldn't think of a less 
dramatic word right now)? Isn't this exactly our job, as part of the Python community?



I propose therefore that we switch from Mercurial/BitBucket to
Git/GitHub and that we start a new GitHub issue tracker (even though it
is shite really). Issues from Tigris can be moved over by hand as
needed.


I don't migrate 3000+ issues by hand. Funny thing is, only yesterday I continued working on my converter script for importing all 
Tigris bugs into a Roundup tracker instance. There are just a few minor unresolved problems with it, so if you think a different bug 
tracker "cuts the mustard", please join and help me with it.


This then gives access to Travis, CodeShip, etc. The point here

is not that they are reliable CIs, it is that they are ways of
promoting and marketing the project in the Git-sphere.

Given Buck, Bazel,… SCons needs to do something to make a new presence
or simply drift 

Re: [Scons-dev] SCons 2.4.0 Released

[Dirk Bächle]

Hi there,

On 22.09.2015 05:09, Bill Deegan wrote:

William,

Sounds good.
I'd like to make sure we get some performance profiling before/after such 
changes to make sure we don't slow SCons down.



I volunteer to weed out some of the old Python 2.x stuff (where x < 7 ;) ) on a separate bug branch. I have all the scons_testsuite 
stuff ready (just like for the slots change), in order to show that there are no large speed penalties coming with it.


Best regards,

Dirk

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

Re: [Scons-dev] Slots ready to release?

[Dirk Bächle]

Hi guys,

On 12.09.2015 22:50, William Blevins wrote:

I'm not sure what I am talking about either.  I think I got email chains mixed 
up...

I don't see any reasons not to do 2.4.0 with slots.



+1 from me...what else? ;)

Regards,

Dirk

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

Re: [Scons-dev] SCons Node ID

[Dirk Bächle]

Hi Anatoly,

On 04.09.2015 06:16, anatoly techtonik wrote:

I have another question about SCons. If I specify target explicitly, it ends up
as str in BUILD_TARGETS and it is impossible to traverse. How do I
transform it to Node if I don't know the type? I.e. how to lookup Node object
by name?



you mean you explicitly specify a target "x" on the command line, but you don't 
know whether it's a File or a Dir?
Can you come up with a short user scenario for this? What is it that you're 
trying to accomplish?

I think we had this discussion some time ago when you asked about how to traverse the Node tree (DAG), the single Nodes are mainly 
addressed (identified) by their full path (relative path and name) relative to the top-level folder of the current SCons build. This 
is what's used while looking up Nodes (exists already, or not?) in the internal FS tree structure, such that we are able to 
distinguish between "vector.h" in two different subdirectories for example.


Hope this helps you a little further.

Best regards,

Dirk

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

Re: [Scons-dev] Anyone any hints…

[Dirk Bächle]

Hi,

just checked this...and it looks like I forgot to add the "suffix" attribute to the "__getattr__" for backward compatibility. I'll 
prepare a pull request, which should only take a few minutes.


Best regards,

Dirk

On 01.09.2015 22:18, Dirk Bächle wrote:

On 01.09.2015 22:00, Bill Deegan wrote:

Could this be related to the slots change which was merged to default a little 
while ago?
-Bill



Judging from the error message, most definitely. ;)

Dirk


On Tue, Sep 1, 2015 at 3:31 PM, Russel Winder <rus...@winder.org.uk 
<mailto:rus...@winder.org.uk>> wrote:

I have been updating my SCons clone, which I use for production use, as
and when. To date nothing has gone wrong, which is great. However, I
just tried building something that involves using the Haskell tool I
synthesised from various stuff from the SCons wiki and elsewhere. This
used to work fine, but now complains about

AttributeError:  object has no attribute
'suffix':

 [...]



___
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] Anyone any hints…

[Dirk Bächle]

On 01.09.2015 22:00, Bill Deegan wrote:

Could this be related to the slots change which was merged to default a little 
while ago?
-Bill



Judging from the error message, most definitely. ;)

Dirk


On Tue, Sep 1, 2015 at 3:31 PM, Russel Winder > wrote:

I have been updating my SCons clone, which I use for production use, as
and when. To date nothing has gone wrong, which is great. However, I
just tried building something that involves using the Haskell tool I
synthesised from various stuff from the SCons wiki and elsewhere. This
used to work fine, but now complains about

AttributeError:  object has no attribute
'suffix':

 [...]



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

Re: [Scons-dev] Requesting feedback on new website design

[Dirk Bächle]

Hey Bill,

On 08.08.2015 00:21, Bill Deegan wrote:

I made a bunch more changes.

http://scons.org/new/

The download page isn't quite right yet, but the navigation is pretty much done.

feedback?



this looks really great now! I like it a lot...and would switch this to live, even though there might still be a few quirks or 
some material missing. Have you tried how the design looks with the default SCons red for the section headings and the old 
background color?

This would then better match our UserGuide/MAN page docs, I think...but I'm not 
a graphical designer.

Again, just awesome!

Dirk

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

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

[Dirk Bächle]

Bill,

On 07.08.2015 16:50, Bill Deegan wrote:

Dirk,

I'd say keep the docs separate.
The pelican stylesheets are actually bootstrap stylesheets.

Where/how should we solicit feedback?



I didn't think about anything fancy. Just waiting a few hours to see if someone 
on this dev ML yells bloody murder should be enough. ;)

Dirk

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

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

[Dirk Bächle]

William,

On 06.08.2015 20:59, William Blevins wrote:

Dirk,
I don't see information on the hardware and/or threads used for your profile 
attachment.
Also, it is interesting that the update time slightly increased.  I assume this 
is a side-effect of the lazy loading overhead.  I am
not worried about it though.
Good work :)



thanks for your feedback. I could list things like OS/machine/RAM...but this is all about the relative comparison of one commit to 
the other. In both runs the same machine and settings were used...does that help, or do you need more information?


@all: I just pushed a new commit for fixing a few tests/tools that were still accessing the Node attributes directly, mainly 
.abspath and .path. Doesn't show up usually, because the __getattr__ is in place in Node/FS.py...but I like to have the core 
sources clean.
During testing I found a problem with test/packaging/rpm/cleanup.py. It will usually PASS, but every now and then when repeatedly 
calling


  python runtest.py test/packaging/rpm/cleanup.py

it fails. I couldn't find an underlying scheme yet, will try further, but is anyone else seeing this behaviour on his machine...or 
has an idea what could go wrong?


Regards,

Dirk

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

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

[Dirk Bächle]

On 06.08.2015 16:26, Bill Deegan wrote:

Dirk,

Push when you are ready.



Ahhh, tsss...pushed it ( https://www.youtube.com/watch?v=cMBh8P1m9Wo )! Only 
for the sexy people... :)


Hi,

the slots changes are online now. For all people interested, please find a comparison 
of before vs after the merge attached.

Best regards,

Dirk



-Bill

On Thu, Aug 6, 2015 at 6:04 AM, William Blevins wblevins...@gmail.com 
mailto:wblevins...@gmail.com wrote:

Sounds like a plan :)

On Aug 6, 2015 3:15 AM, Dirk Bächle tshor...@gmx.de 
mailto:tshor...@gmx.de wrote:

Hi there,

just wanted to let you know that I have prepared a new trunk (default) with the 
change to slots in the core sources on
my local machine. Full testsuite (runtest.py -a) shows no errors on my 
side...and I'm currently running it through the
scons_testsuite (https://bitbucket.org/dirkbaechle/scons_testsuite) to 
see if real projects might be affected somehow.

My plan is to push these changes to the main repo tonight (23-?? UTC), 
unless someone objects...

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 mailto:Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev




Title: Comparing slotmerge_ref to slotmerge_done



wonderbuild
Times

Runrun [s]update [s]update_implicit [s]
Previous1043.716.916.6
Current1030.618.117.7
Factor0.991.071.06

Memory

Runrun [MByte]update [MByte]
Previous364.0337.4
Current243.3211.8
Factor0.670.63

Profiling

Runrun [s]update [s]update_implicit [s]
Previous1137.426.326.3
Current1064.928.327.8
Factor0.941.081.06

bombono
Times

Runrun [s]update [s]update_implicit [s]
Previous364.56.94.4
Current362.77.14.6
Factor1.001.031.04

Memory

Runrun [MByte]update [MByte]
Previous137.3132.5
Current117.4111.7
Factor0.850.84

Profiling

Runrun [s]update [s]update_implicit [s]
Previous392.711.27.3
Current378.912.18.0
Factor0.961.081.09

mongo
Times

Runrun [s]update [s]update_implicit [s]
Previous3518.942.322.8
Current3500.843.222.8
Factor0.991.021.00

Memory

Runrun [MByte]update [MByte]
Previous360.3359.5
Current290.4290.7
Factor0.810.81

Profiling

Runrun [s]update [s]update_implicit [s]
Previous3571.462.934.6
Current3539.064.036.2
Factor0.991.021.04

ascend
Times

Runrun [s]update [s]update_implicit [s]
Previous30.62.31.7
Current30.82.31.8
Factor1.011.021.04

Memory

Runrun [MByte]update [MByte]
Previous99.2100.2
Current86.187.1
Factor0.870.87

Profiling

Runrun [s]update [s]update_implicit [s]
Previous32.03.32.5
Current32.43.42.7
Factor1.011.021.06

sconsbld
Times

Runrun [s]update [s]update_implicit [s]
Previous422.930.321.5
Current385.132.123.0
Factor0.911.061.07

Memory

Runrun [MByte]update [MByte]
Previous395.7416.9
Current252.6258.0
Factor0.640.62

Profiling

Runrun [s]update [s]update_implicit [s]
Previous515.946.332.3
Current474.850.936.3
Factor0.921.101.12

questfperf
Times

Runrun [s]update [s]update_implicit [s]
Previous964.421.514.4
Current940.322.915.5
Factor0.971.061.08

Memory

Runrun [MByte]update [MByte]
Previous299.7307.7
Current205.5213.8
Factor0.690.69

Profiling

Runrun [s]update [s]update_implicit [s]
Previous972.131.120.8
Current966.134.523.8
Factor0.991.111.15

lumiera
Times

Runrun [s]update [s]update_implicit [s]
Previous428.16.04.4
Current426.46.24.6
Factor1.001.031.03

Memory

Runrun [MByte]update [MByte]
Previous121.9128.6
Current107.0110.3
Factor0.880.86

Profiling

Runrun [s]update [s]update_implicit [s]
Previous459.39.26.8
Current462.59.67.2
Factor1.011.051.06

mapnik
Times

Runrun [s]update [s]update_implicit [s]
Previous889.410.25.5
Current890.210.45.5
Factor1.001.021.00

Memory

Runrun [MByte]update [MByte]
Previous161.8163.3
Current127.2137.0
Factor0.790.84

Profiling

Runrun [s]update [s]update_implicit [s]
Previous895.615.58.5
Current900.016.28.8
Factor1.001.041.05



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

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

[Dirk Bächle]

Hi there,

just wanted to let you know that I have prepared a new trunk (default) with the change to slots in the core sources on my local 
machine. Full testsuite (runtest.py -a) shows no errors on my side...and I'm currently running it through the scons_testsuite 
(https://bitbucket.org/dirkbaechle/scons_testsuite) to see if real projects might be affected somehow.


My plan is to push these changes to the main repo tonight (23-?? UTC), unless 
someone objects...

Best regards,

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

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

[Dirk Bächle]

Bill,

On 01.08.2015 20:23, Bill Deegan wrote:

Dirk,

What would be the reason to put slots on 2.4 instead of default branch?
If needed we can always branch from 2.3.6 to make a 2.3 branch and patch that.



I, personally, am quite confident that merging directly to default should work fine. It's simply to encounter any remaining FUD 
that might get raised by people...and to play it on the safe side as much as possible.


Regards,

Dirk

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

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

[Dirk Bächle]

Bill,

On 30.07.2015 17:36, Bill Deegan wrote:

 From the code I've looked at if you have libxml2  libxslt that is preferred, 
and then if not it will use lxml.



your assumption is correct, this is done because libxml2 is faster in general.

It seems that libxml2 and pure lxml have different behaviour regarding normalizing namespaces and that's where the diff comes 
from. This makes at least the validation in the SernaFree XML editor choke for the lxml output...:(


I'm investigating this a little further and will try to find a way around this. I'd really like to have the (almost) same output for 
both XML toolchains, such that it gets accepted by most XML editors out there.


@William: You said that after installing an additional package the processing got faster and correct? My guess would be that you now 
have a lxml distro/package that relies on libxml2 under the hood. This makes the error go away of course...



I'll keep you posted, best regards,

Dirk

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

Re: [Scons-dev] Cross-language support

[Dirk Bächle]

Hi guys,

sorry for chiming in so late.

On 28.07.2015 23:44, Gary Oberbrunner wrote:

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



Doing this in parallel with the slots change sounds good to me too. +1


-- Gary

On Tue, Jul 28, 2015 at 2:01 PM, Bill Deegan b...@baddogconsulting.com 
mailto:b...@baddogconsulting.com wrote:

Gary,

For such a change we should bump the second digit?
2.4?

I agree we should not turn down a change because it will cause rebuilds 
where the past didn't as long as it is now more correct
(which it should be with this change).


Yes, forward is the way to go. ;)


Also agree we should be verbose in our notification of the impacts of the new change 
to avoid (as much as we can) surprises.



I think (better: hope) we did a good enough job for the slots stuff on this. For the scanner changes, I see them more like a 
fix...so a single announcement should be sufficient?


Finally, and just in case I haven't done so already, I'd like to thank William for all the work he's done on this issue. I couldn't 
help as much as I would've liked, but with Gary's support you tackled this down and brought it to a good end. Kudos to you...bravo!



Best regards,

Dirk

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

Re: [Scons-dev] Adding Visual Studio 2015 Support to SCons

[Dirk Bächle]

Bill,

On 15.07.2015 23:51, Bill Deegan wrote:

Rob,

Thanks for the pull request.
I looked at it yesterday.
I was just refreshing my memory what tests we had for supporting each version 
of visual studio.



just a short question regarding the release schedule: It has been a while since the latest version was released, so far I haven't 
heard of any severe problems from users. Do you still have important pending fixes, based on your experiences with the 
build/packaging system (anything in the direction of doc creation perhaps)? Should I now start the new release branch for 2.4 and 
merge the switch to slots stuff to it? Or would you like me to wait...



Best regards,

Dirk


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

Re: [Scons-dev] Repo not wiki for tools and add-ons

[Dirk Bächle]

Hi Russel,

On 05.07.2015 20:57, Russel Winder wrote:

On Sun, 2015-07-05 at 11:22 +0200, Dirk Bächle wrote:



[…]

  https://bitbucket.org/scons/scons-contrib/admin/access
 

thanks a lot for creating this Bill.


Indeed, I think we can get some capital out of this initiative.



[…]

I would like to see another folder here for contributed config
snippets (automake-like checks for libs n' stuff).
Ideally, the tools/config folders have the same name for the SCons
core distribution and the contrib package, such that we can
easily blend them together via import at runtime...


Mayhap we should iterate over a diagram of this structure rather than
just words. I think you are suggesting:

.
+- tools
|  +- config
+- scripts
+- docs
*- config

But I am not sure I see why. (Probably me me slow.)



my idea was more something like this:

scons_contrib
└── SCons
├── docs
├── SConf
│   └── __init__.py
├── scripts
└── Tool
└── __init__.py

(see also attached screenshot). By setting the PYTHONPATH in the scons script 
properly, a user could then do

  import SCons.Tool

in his build scripts, without having to care where exactly (scons or scons-contrib) the actual Tool is coming from. Not sure whether 
this would work at all though...;)


Best regards,

Dirk

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

Re: [Scons-dev] Repo not wiki for tools and add-ons

[Dirk Bächle]

Hi,

On 04.07.2015 20:46, Russel Winder wrote:

On Sat, 2015-07-04 at 13:17 -0400, Bill Deegan wrote:

Russel,

I've created:

https://bitbucket.org/scons/scons-contrib/admin/access



thanks a lot for creating this Bill.



[...]


Would it be worth having 3 base dirs:
tools
scripts
docs
?



I would like to see another folder here for contributed config snippets 
(automake-like checks for libs n' stuff).
Ideally, the tools/config folders have the same name for the SCons core distribution and the contrib package, such that we can 
easily blend them together via import at runtime...



Or just have tools live in the root of the repo?


I think idea of having tools as a sub-heirarchy is fitting and gives
most flexibility. Indeed I wonder if we go with this, we have had
sufficient debate on structure to begin to act.

We do perhaps need to have criteria for accepting new tools, and
ejecting current tools. I have a few Mercurial repositories on
BitBucket that are immediate candidates, but the question is whether
they are ready or whether they would be better staying separate for
now. Clearly I could put them all in but would that be the right thing
to do just now?


The question here is: What is the scons-contrib supposed to do? So far I got the impression it's a replacement for all the code 
snippets in the Wiki that haven't found a place in their own repo yet. This would clearly exclude the already existing Tools (see 
ToolsIndex) from this list, and we don't move them to scons-contrib but let them stay where they are.
Then the regular restrictions for moving directly into the core would still hold (requires docs and tests). The evolution chain 
would be:


  Wiki snippet - scons-contrib - external Tool (own repo) - SCons core


If you're aiming for a contains-all-external-tools-and-snippets repo, yes, we would need to have some clear criteria for accepting 
them. In my opinion, it's all about the user here. He expects a certain degree of maturity for the Tools and add-ons we provide, 
such that they work out-of-the-box for him. Another difficult task would be to find a single (!) maintainer for organizing this 
whole bunch of loose ends.


Just my 2 cents.

Best regards,

Dirk

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

Re: [Scons-dev] Release 2.3.5

[Dirk Bächle]

Bill,

On 23.06.2015 01:27, Bill Deegan wrote:

Dirk,

If I build docs with system python it works fine.

If I install libxml2-python it still failes with zero length files.
If I uninstall lxml and run it again I get:

[...]

O.k. got it. Needed to also install libxslt. Probably need to figure out a way 
to give messaging on this rather than silently fail.



yes, this explains things. The Docbook Tool uses xsltproc/xmllint as a fallback when no libxslt is installed. But for the MAN page 
creation there has to be libxslt (see URL in my last email), so we need to add another check to doc/SConscript I guess.


Thanks for your detective work!

Dirk

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

Re: [Scons-dev] Release 2.3.5

[Dirk Bächle]

Bill,

On 22.06.2015 23:13, Bill Deegan wrote:

Dirk,

Here's log:
https://pastebin.mozilla.org/8837564



thanks...looks like the lxml-Python branch of the doc toolchain doesn't work correctly. Can you install the python-libxml2 binding 
additionally and try again?


Dirk

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