[Scons-dev] SCons Version 3.0.3 Released
A new SCons release, 3.0.3, is now available on the SCons download page: https://scons.org/pages/download.html Here is a summary of the changes since 3.0.1: NEW FUNCTIONALITY - Properly support versioned shared libraries for MacOS. We've also introduced two new env variables APPLELINK_CURRENT_VERSION and APPLELINK_COMPATIBILITY_VERSION which will specify what is passed to the linkers -current_version and -compatibility_version flags. If not specified they will be derived from SHLIBVERSION as such: - APPLELINK_CURRENT_VERSION = SHLIBVERSION - APPLELINK_COMPATIBILITY_VERSION = all but the last digit in SHLIBVERSION with .0 appended. Note that the values of the above will be validated. Valid format for either APPLELINK variable is X[.Y[.Z]] where 0 <= X <= 65535, 0 <= Y <= 255, 0 <= Z <= 255. - Add flag must_exist to SConscript() call to fail on missing script. Not failing on missing script is now considered deprecated, and the first instance will print a deprecation message. - Add xz compression format to packaging choices. - Add Textfile/Substfile to default environment. (issue #3147) - Added virtualenv support. A new function Virtualenv() determines whether SCons runs in a virtualenv. The search PATH may also be extended to prefer executables from the current virtualenv over the ones provided by base environment. New option --enable-virtualenv provided to import some virtualenv-related variables to SCons and extend every env['ENV']['PATH'] automatically. New option --ignore-virtualenv disables this. Two environment variables, SCONS_ENABLE_VIRTUALENV and SCONS_IGNORE_VIRTUALENV are supported for the same purpose. DEPRECATED FUNCTIONALITY - Going forward calling SConscript on a non-existing SConscript file will issue a warning. Currently it will issue a deprecation notice. CHANGED/ENHANCED EXISTING FUNCTIONALITY - Recognize new java 9, 10, 11 (as 9.0 and 10.0, 11.0) DOCUMENTATION - Update some doc examples for Py3: map() now returns an iterable instead of a list. FIXES - Fix issue #2980 with credit to Piotr Bartosik (and William Blevins). This is an issue where using TimeStamp-MD5 Decider and CacheDir can yield incorrect md5's being written into the .sconsign. The difference between Piotr Bartosik's patch and the current code is that the more complicated creation of file to csig map is only done when the count of children for the current node doesn't match the previous count which is loaded from the sconsign. Thanks to Bernard Blackham, William Deegan, Ray Donnelly, Andrew Featherstone, Arda Fu, Philipp Maierhöfer, Matthew Marinets, Fredrik Medley, Daniel Moody, Gary Oberbrunner, Jonathon Reinhart, Zachary Tessler, Paweł Tomulik, Richard West, Mats Wichmann, Bernhard M. Wiedemann, and Hao Wu for their contributions to this release. Contributors are listed alphabetically by their last name. git shortlog --no-merges -ns 3.0.1..HEAD 254 William Deegan 79 Daniel Moody 73 Mats Wichmann 17 Paweł Tomulik 16 Andrew Featherstone 8 grbd 7 maiphi 6 Gary Oberbrunner 6 Daniel 4 Hao Wu 3 Gabriel Russell 2 MatthewMarinets 2 Jonathon Reinhart 2 ArdaFu 1 Bernhard M. Wiedemann 1 Isaac Pascual Monells 1 Fredrik Medley 1 Philipp Maierhoefer 1 Piotr Kasprzyk 1 Ray Donnelly 1 Zachary Tessler 1 cclauss ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] doc generation fails with Python3
Here's some scripts for building python (2.7,3.5..) with libxslt, libxml2 https://github.com/bdbaddog/python_build_scripts On Mon, Jan 7, 2019 at 11:40 AM Mats Wichmann wrote: > On 1/7/19 9:02 AM, Bill Deegan wrote: > > Mats, > > > > I think the issue is that lxml doesn't really work for all doc generation > > steps. > > I've had issues in the past. > > Does libxml2 and libxslt build for python 3? > > > > -Bill > > humm. I don't have that available for Fedora - only python2-libxslt, > not python3. > > I do have available both versions of python-lxml and python-libxml2. > > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] doc generation fails with Python3
On 1/7/19 9:02 AM, Bill Deegan wrote: > Mats, > > I think the issue is that lxml doesn't really work for all doc generation > steps. > I've had issues in the past. > Does libxml2 and libxslt build for python 3? > > -Bill humm. I don't have that available for Fedora - only python2-libxslt, not python3. I do have available both versions of python-lxml and python-libxml2. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] doc generation fails with Python3
Mats, I think the issue is that lxml doesn't really work for all doc generation steps. I've had issues in the past. Does libxml2 and libxslt build for python 3? -Bill On Mon, Jan 7, 2019 at 10:48 AM Mats Wichmann wrote: > > Following protocol to get issue on a mailing list before filing a github > ticket. I can't see how this is a "users" issue so sending here. > Strictly speaking this is not even scons itself, but clearly part of the > scons project. > > One doc generation step does not work if Python 3 is used. From the > doc/overview.rst instructions: > > python bin/docs-update-generated.py > > if you invoke that with Python 2.x it goes through the docs collecting > information, then generates a few files. > > if you invoke it with Python 3.x: > > > $ python3 bin/docs-update-generated.py > Generating entity files... > error in src/engine/SCons/Subst.xml > Traceback (most recent call last): > File "bin/scons-proc.py", line 351, in > h = parse_docs(args, False) > File "bin/scons-proc.py", line 76, in parse_docs > h.parseContent(content, include_entities) > File "/home/mats/Work/scons.doc/bin/SConsDoc.py", line 792, in > parseContent > t.parseContent(content, include_entities) > File "/home/mats/Work/scons.doc/bin/SConsDoc.py", line 590, in > parseContent > self.root = etree.fromstring(content) > File "src/lxml/etree.pyx", line 3213, in lxml.etree.fromstring > File "src/lxml/parser.pxi", line 1872, in lxml.etree._parseMemoryDocument > ValueError: Unicode strings with encoding declaration are not supported. > Please use bytes input or XML fragments without declaration. > > > > scons's "custom xml" has lots of encoding declarations, if in fact > that's what it is referring to: > > > > I'm not completely sure that is the complaint. There are StackOverflow > articles on this topic from other projects: > > > https://stackoverflow.com/questions/15830421/xml-unicode-strings-with-encoding-declaration-are-not-supported > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
[Scons-dev] doc generation fails with Python3
Following protocol to get issue on a mailing list before filing a github ticket. I can't see how this is a "users" issue so sending here. Strictly speaking this is not even scons itself, but clearly part of the scons project. One doc generation step does not work if Python 3 is used. From the doc/overview.rst instructions: python bin/docs-update-generated.py if you invoke that with Python 2.x it goes through the docs collecting information, then generates a few files. if you invoke it with Python 3.x: $ python3 bin/docs-update-generated.py Generating entity files... error in src/engine/SCons/Subst.xml Traceback (most recent call last): File "bin/scons-proc.py", line 351, in h = parse_docs(args, False) File "bin/scons-proc.py", line 76, in parse_docs h.parseContent(content, include_entities) File "/home/mats/Work/scons.doc/bin/SConsDoc.py", line 792, in parseContent t.parseContent(content, include_entities) File "/home/mats/Work/scons.doc/bin/SConsDoc.py", line 590, in parseContent self.root = etree.fromstring(content) File "src/lxml/etree.pyx", line 3213, in lxml.etree.fromstring File "src/lxml/parser.pxi", line 1872, in lxml.etree._parseMemoryDocument ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration. scons's "custom xml" has lots of encoding declarations, if in fact that's what it is referring to: I'm not completely sure that is the complaint. There are StackOverflow articles on this topic from other projects: https://stackoverflow.com/questions/15830421/xml-unicode-strings-with-encoding-declaration-are-not-supported ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
