[Scons-dev] SCons 4.7.0 Release

[Bill Deegan]

A new SCons release, 4.7.0, is now available on the SCons download page:

https://scons.org/pages/download.html

Here is a summary of the changes since 4.6.0:

NEW FUNCTIONALITY
-

- Method unlink_files was added to the TestCmd class that unlinks a list of
files
  from a specified directory.  An attempt to unlink a file is made only
when the
  file exists; otherwise, the file is ignored.

CHANGED/ENHANCED EXISTING FUNCTIONALITY
---

- Add an optional argument list string to configure's CheckFunc method so
  that the generated function argument list matches the function's
  prototype when including a header file. Fixes GH Issue #4320
- Now supports pre-release Python 3.13
- Support for Python versions without support for the `threading` package
has been removed
- Dropped three unused warning classes: DeprecatedSourceCodeWarning,
  TaskmasterNeedsExecuteWarning, DeprecatedMissingSConscriptWarning.
* Two warning classes that are actually used were added to manpage section
on
  enabling warnings (cache-cleanup-error, future-reserved-variable).

FIXES
-

- Fix of the --debug=sconscript option to return exist statements when
using return
  statement with stop flag enabled
- MSVS: prevent overwriting the SCons environment variable SCONS_HOME with
the OS
  environment value of SCONS_HOME in the msvs tool.
- MSVC: Fix the detection of Visual Studio 2015 Express ('14.0Exp') by
adding a
  registry key definition and updating the installation root-relative
registry value
  at runtime for the location of the VC folder.
- MSVS: Fix the msvs project generation test for MSVS 6.0 to use the
correct name of
  the generated project file.
- MSVS: Fix the msvs project generation test scripts so that "false
positive" tests
  results are not possible when the initial build is successful and the
command-line
  build of the project file fails.
- On Windows platform, when collecting command output (Configure checks),
  make sure decoding of bytes doesn't fail.
- Documentation indicated that both Pseudo() and env.Pseudo() were usable,
  but Pseudo() did not work; is now enabled.
- Improve handling of file data that SCons itself processes - as in
  scanners - try harder to decode non-UTF-8 text.
- PyPackageDir no longer fails if passed a module name which cannot be
found,
  now returns None.
- Add locking around creation of CacheDir config file. Fixes issue #4489.

IMPROVEMENTS


- Use of NotImplemented instead of NotImplementedError for special methods
  of _ListVariable class
- The NewParallel scheduler is now the default, the `tm_v2` flag is removed,
  and the old scheduler is opt-in under `--experimental=legacy_sched`.
Additionally,
  the new scheduler is now used for -j1 builds as well.
  NOTE: This should significantly improve SCons performance for larger
parallel builds
(Larger -j values)
- CacheDir writes no longer happen within the taskmaster critical section,
and therefore
  can run in parallel with both other CacheDir writes and the taskmaster
DAG walk.
- The NewParallel scheduler now only adds threads as new work requiring
execution
  is discovered, up to the limit set by -j. This should reduce resource
utilization
  when the achievable parallelism in the DAG is less than the -j limit.
- Dumping an environment with `json` formatting will now explicitly specify
if a given
  value cannot be serialized.

PACKAGING
-

- Remove unnecessary dependencies on pypi packages from setup.cfg
- SCons documentation build can now be controlled through SKIP_DOC
  variable - rather than just true/false can now specify
  skip none, skip all, skip pdf docs, skip api docs.

DOCUMENTATION
-

- Fixed the Scanner examples in the User Guide to be runnable and added
  some more explanation. Clarified discussion of the scanner function in
  the Scanner Objects section of the manpage.
- The manpage entry for Pseudo was clarified.
- The manpage entry for SharedLibrary was clarified.
- Update API docs for Warnings framework; add two warns to manpage
  enable/disable control.
- More consistent use of  in the manpage.  A few links added.
  A warning about overwriting env['ENV'] and one about Configure
  checks possibly not running in in no-exec mode also added.
- Clarify how SCons finds the project top directory, and what that is used
for.
- Clarify MergeFlags usage of a dict argument.

DEVELOPMENT
---

- Fix sphinx config to handle SCons versions with post such as: 4.6.0.post1
- Created SCons.Util.sctyping to contain complex type information, allowing
  for repo-wide type hinting without causing cyclical dependencies.

Thanks to the following contributors listed below for their contributions
to this release.
==
.. code-block:: text

git shortlog --no-merges -ns 4.6.0..HEAD
26  Andrew Morrow
24  Mats Wichmann
14  William Deegan
 7  Joseph 

Re: [Scons-dev] Struck in running c program in scons

[Bill Deegan]

Also of note, these type of queries should be sent to scons-users mailing
list and not scons-dev.
scons-dev is meant for internal development of SCons itself and not user
issues when using the tool.

On Wed, Feb 21, 2024 at 8:03 AM Mats Wichmann  wrote:

> On 2/21/24 03:08, Gopi Maila wrote:
> > image.pngimage.pngHi *,
> >
> > I was not able to execute the c program in command prompt using scons.
> > Can you please guide me on how to do that?
>
> Hi again...
>
> somebody who can see the screenshots told me your filename is
> SConstruct.txt.  SCons doesn't expect that, you can call it SConstruct
> (no suffix), or SConstruct.py (since the contents are in Python);
> all-lowercase letters works too. SCons should find that just fine, or
> you can invoke it explicitly:
>
> scons -f SConstruct.txt
>
> Hope that helps...
> ___
> 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] SCons 4.6.0 released

[Bill Deegan]

A new SCons release, 4.6.0, is now available on the SCons download page:

https://scons.org/pages/download.html


Here is a summary of the changes since 4.5.2:

NEW FUNCTIONALITY
-

- D compilers : added support for generation of .di interface files.
  New variables DI_FILE_DIR, DI_FILE_DIR_PREFIX, DI_FILE_DIR_SUFFIX,
  DI_FILE_SUFFIX.
- MSVC: If available, native arm64 tools will be used on arm64 hosts for
VS2022.
- MSVC: If necessary, automatically define VSCMD_SKIP_SENDTELEMETRY for
VS2019 and later
  on arm64 hosts when using an arm (32-bit) build of python to prevent a
powershell
  error pop-up window (powershell dll not found).
- Add a LIBLITERALPREFIX variable which can be set to the linker's
  prefix for considering a library argument unmodified (e.g. for the
  GNU linker, the ':' in '-l:libfoo.a'). Fixes Github issue #3951.


CHANGED/ENHANCED EXISTING FUNCTIONALITY
---

- When debugging (--debug=pdb), the filenames SConstruct and SConscript
  are now recognized when manipulating breakpoints. Previously,
  only a full pathname to an sconscript file worked, as pdb requires
  a .py extension to open a file that is not an absolute path.
- Three unused non-public methods of the Environment Base class
  were dropped: get_src_sig_type, get_tgt_sig_type, _changed_source.
  These were unused remnants of the previously removed SourceSignatures
  and TargetSignatures features (dropped in 3.1.2).
- The --debug flag now has a 'json' option which will write information
  generated by --debug={count, memory, time, action-timestamps} and about
  the build.
- Obsoleted YACCVCGFILESUFFIX, it's being replaced by
YACC_GRAPH_FILE_SUFFIX.
  If YACC_GRAPH_FILE_SUFFIX is not set, it will respect YACCVCGFILESUFFIX.
- The yacc tool now understands the bison behavior of --header, --defines
  and --graph being called without an option-argument as being synonyms
  for -d (first two) and -g. -H also recognized as a synonym for -d.
  Default value for $YACC_GRAPH_FILE_SUFFIX changed to '.gv' to match
  current bison default (since bison 3.8). Set this variable to '.dot'
  if using byacc. Fixes #4326 and #4327.
- MSVC: When trying to find a valid msvc batch file, the existence of the
msvc compiler
  executable is verified for VS6 to VS2015 to avoid executing the msvc
batch file when
  the host/target tool is known not to be present. Always check that the
msvc compiler
  executable is found on the msvc script environment path after running the
msvc batch
  file.  This is predominately needed for recent versions of Visual Studio
where the msvc
  batch file exists but an individual msvc toolset may not support the
host/target
  architecture combination.  For example, when using VS2022 on arm64, the
arm64 native
  tools are only installed for the 14.3x toolsets.
- MSVC: When the msvc compiler executable is not found during setup of the
msvc
  environment, the warning message issued takes into account whether or not
a
  possibly erroneous compiler executable was already present in the scons
environment
  path.  See CHANGES.txt for details.
- Extend range of recognized Java versions to 20.
- Builder calls (like Program()) now accept pathlib objects in source lists.
- The Help() function now takes an additional keyword argument keep_local:
  when starting to build a help message, you can now retain help from
AddOption
  calls (options added for the project_, but omit help for SCons' own
cmdline
  options with "Help(newtext, append=True, local_only=True)".
- Calling SConscript() with a nonexistent file is now an error.
  Previously this succeeded - prior to SCons 3.0, silently; since 3.0, with
  a warning. Developers can still instruct such an SConscript() call not
  to fail by being explicit: pass keyword argument "must_exist=False".
  The "--warn=missing-sconscript" commandline option is no longer available
  as the warning was part of the transitional phase.
- Add missing directories to searched paths for mingw installs
- SCons.Util.types renamed to to SCons.Util.sctypes to avoid any possible
  confusion with the Python stdlib "types" module. Note that it was briefly
  (for 4.5.x only) possible to import directly from SCons.Util.types,
  although the preferred usage remains to import from SCons.Util only.
  Any code that did the direct import will have to change to import from
  SCons.Util.sctypes.
- Add JDK 21 LTS support
- The newly added --debug=sconscript option (new) will output notices when
  entering an exiting each SConscript as they are processed.

FIXES
-

- Fixed: when using the mingw tool, if an msys2 Python is used (os.sep
  is '/' rather than the Windows default '\'), certain Configure checks
  could fail due to the construction of the path to run the compiled check.
- C scanner's dictifyCPPDEFINES routine did not understand the possible
  combinations of CPPDEFINES - not aware of a "name=value" string either
  embedded in a sequence, or by itself.  The 

[Scons-dev] SCons 4.5.2 Released

[Bill Deegan]

A new SCons release, 4.5.2, is now available on the SCons download page:

https://scons.org/pages/download.html

Here is a summary of the changes since 4.5.1:

FIXES
-

-  Fix a problem (#4321) in 4.5.0/4.5.1 where ParseConfig could cause an
   exception in MergeFlags when the result would be to add preprocessor
   defines to existing CPPDEFINES. The following code illustrates the
   circumstances that could trigger this:
  env=Environment(CPPDEFINES=['a'])
  env.Append(CPPDEFINES=['b'])
  env.MergeFlags({'CPPDEFINES': 'c'})

PACKAGING
-

- Remove the redundant `wheel` dependency from `pyproject.toml`,
  as it is added automatically by the setuptools PEP517 backend.


Thanks to the following contributors listed below for their contributions
to this release.
==
.. code-block:: text

git shortlog --no-merges -ns 4.5.1..HEAD
 3  Mats Wichmann
 2  William Deegan
 1  Michał Górny
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] SCons 4.5.1 Released

[Bill Deegan]

A new SCons release, 4.5.1, is now available on the SCons download page:

https://scons.org/pages/download.html

Here is a summary of the changes since 4.5.0:

FIXES
-

- Fix a problem in 4.5.0 where using something like the following code
  will cause a Clone()'d environment to share the CPPDEFINES with the
  original Environment() which was cloned. Causing leakage of changes
  to CPPDEFINES when they should be completely independent after the Clone.
  env=Environment(CPPDEFINES=['a'])
  env.Append(CPPDEFINES=['b']) (or AppendUnique,Prepend,PrependUnique)
  env1=env.Clone()
  env1.Append(CPPDEFINES=['c']) (or any other modification, but not
overwriting CPPDEFINES)
  Now env['CPPDEFINES'] will contain 'c' when it should not.


Thanks to the following contributors listed below for their contributions
to this release.
==
.. code-block:: text

git shortlog --no-merges -ns 4.5.0..HEAD

 3  William Deegan
 1  Mats Wichmann
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] SCons 4.5.0 Released

[Bill Deegan]

A new SCons release, 4.5.0, is now available on the SCons download page:

https://scons.org/pages/download.html


Here is a summary of the changes since 4.4.0:

NOTE: If you build with Python 3.10.0 and then rebuild with 3.10.1 (or
higher), you may
  see unexpected rebuilds. This is due to Python internals changing
which changed
  the signature of a Python Action Function.

NOTE: If you use a dictionary to specify your CPPDEFINES, you may see an
unexpected rebuild.
  The insertion order of dictionary keys is now preserved when
generating the command line.
  Previously these were sorted alphabecially.  This change to the
command line,
  while generating identical set of CPPDEFINES can change order and
cause a rebuild.


NEW FUNCTIONALITY
-

- Added ValidateOptions() which will check that all command line options
are in either
  those specified by SCons itself, or by AddOption() in
SConstruct/SConscript.  It should
  not be called until all AddOption() calls are completed. Resolves Issue
#4187
- Added --experimental=tm_v2, which enables Andrew Morrow's NewParallel Job
implementation.
  This should scale much better for highly parallel builds.  You can also
enable this via SetOption().
- Added FILE_ENCODING, to allow explicitly setting the text encoding for
files
  written by the Textfile() and Substfile() builders. If not specified,
Textfile() and Substfile() builders
  will write files as UTF-8.


DEPRECATED FUNCTIONALITY


- The qt tool has been renamed qt3.

CHANGED/ENHANCED EXISTING FUNCTIONALITY
---

- Added -fsanitize support to ParseFlags().  This will propagate to CCFLAGS
and LINKFLAGS.
- Calling EnsureSConsVersion() and EnsurePythonVersion() won't initialize
  DefaultEnvironment anymore.
- The console message from the Chmod() action function now displays
  octal modes using the modern Python syntax (0o755 rather than 0755).
- Migrated logging logic for --taskmastertrace to use Python's logging
module. Added logging
  to NewParallel Job class (Andrew Morrow's new parallel job implementation)
- Preliminary support for Python 3.12.
- Run LaTeX after biber/bibtex only if necessary
- Configure context methods CheckLib and CheckLibWithHeader now expose
  two additional keyword arguments: 'append', which controls whether to
append
  (the default) or prepend discovered libraries to $LIBS, and 'unique',
  which controls whether to add the library if it is already in the $LIBS
  list. This brings the library-adding functionality in Configure in line
  with the regular Append, AppendUnique, Prepend and PrependUnique methods.
- CPPDEFINES values added via a dictionary type are longer sorted by
  key. This used to be required to maintain a consistent order of
  commandline arguments between SCons runs, but meant macros were not
  always emitted in the order entered. Sorting is no longer required
  after Python interpreter improvements.  There might be a one-time
  rebuild of targets that involved such sorted keys in their actions.
- Renamed the 'qt' tools to 'qt3' since the logic in that tool is only for
QT version 3.
  Renamed all env vars which affect qt3 from QT_ to QT3_.  If you are still
using SCons
  to build QT 3 code, you'll need to update your SConscripts.  Note that
using 'qt' tool
  has been deprecated for some time.


FIXES
-

- Added missing newline to generated compilation database
(compile_commands.json)
- A list argument as the source to the Copy() action function is now
handled.
  Both the implementation and the strfunction which prints the progress
  message were adjusted.
- The Java Scanner processing of JAVACLASSPATH for dependencies (behavior
  that was introduced in SCons 4.4.0) is adjusted to split on the system's
  search path separator instead of on a space. The previous behavior meant
  that a path containing spaces (e.g. r"C:\somepath\My Classes") would
  lead to unexpected errors. If the split-on-space behavior is desired,
  pre-split the value: instead of: env["JAVACLASSPATH"] = "foo bar baz"
  use: env["JAVACLASSPATH"] = env.Split("foo bar baz")
  There is no change in how JAVACLASSPATH gets turned into the -classpath
  argument passed to the JDK tools.
- Ninja: Fix execution environment sanitation for launching ninja.
Previously if you set an
  execution environment variable set to a python list it would crash. Now it
  will create a string joining the list with os.pathsep
- Fixed command line argument --diskcheck: previously a value of 'none' was
ignored.
  SetOption('diskcheck','none') is unaffected, as it did not have the
problem.
- Fixed Issue #4275 - when outputting compilation db and TEMPFILE was in
use, the compilation db would have
  command lines using the generated tempfile for long command lines,
instead of the full command line for
  the compilation step for the source/target pair.
- A refactor in the caching logic for version 4.4.0 left Java inner classes
  failing 

Re: [Scons-dev] Proposal for a more efficient version of the Parallel scheduler

[Bill Deegan]

Adam,

We just pushed a new parallel job implementation by Andrew Morrow which
might be worth trying in your environment.
It's currently an experimental feature enabled by --experimental=tm_v2 or
SetOption('experimental','tm_v2')

-Bill

On Tue, Jul 9, 2019 at 11:35 AM Adam Gross via Scons-dev <
scons-dev@scons.org> wrote:

> In VMware builds, the sheer number of tasks (33000 leaf tasks in the first
> iteration of ESX builds, for example) means that Parallel.start can take up
> to 20 minutes simply collecting and preparing tasks over the course of a
> build. I started a project to look at batch task handling in order to
> support remote caching (e.g. asking the cache for 1000 nodes at a time
> instead of 1) and realized that the approach that I want to take actually
> makes normal builds more efficient as well. In this e-mail, I’d like to
> explain my proposal so I can get your thoughts on it.
>
>
>
> --- Current Parallel.start performance problems ---
>
>
>
> Reference:
> https://github.com/SCons/scons/blob/master/src/engine/SCons/Job.py#L369
>
>
>
> In the current implementation, SCons collects just enough tasks to
> dispatch to the thread pool such that the number of active jobs is equal to
> the max number of jobs. It then waits for at least one job to be done,
> gathers all finished jobs, then repeats the process of collecting enough
> tasks to have jobs==self.maxjobs.
>
>
>
> Waiting on at least one job to be done misses an opportunity to keep
> calling taskmaster.next_task() and task.prepare() while jobs are active.
> These calls are not cheap for many reasons, including that it initiates
> scanning of source nodes.
>
>
>
> --- Proposal ---
>
>
>
> A first rough draft is contained in draft pull request
> https://github.com/SCons/scons/pull/3404 . In this form it is an
> alternative child class of Parallel; it could just replace it if people
> felt strongly.
>
>
>
> I would like to implement an alternative to the Parallel class that only
> waits for jobs to complete if there are no tasks left (i.e.
> taskmaster.next_task() returns None). It is optimized for keeping
> jobs==self.maxjobs but otherwise, will keep looking for more tasks. If
> there are no more tasks left, it waits for a job to complete and then
> rechecks whether there are any tasks left, just in case other tasks were
> unblocked by its completion.
>
>
>
> One very useful side effect is that this class will be collecting lists of
> tasks instead of operating on one at a time, so it serves as a useful
> building block towards remote caching. The current one-at-a-time cache
> retrieval approach wouldn’t work for remote caching due to network latency
> but this approach can.
>
>
>
> Please let me know what you think either over e-mail or on the
> aforementioned pull request.
>
>
>
> Thanks,
>
> Adam Gross
> ___
> 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] Builder._createNodes appears to handle slist incorrectly

[Bill Deegan]

I'd put money on it not being broken and your usage perhaps not quite
right..

There's a lot of code in your PR.

You might try adding `multi=True` when you create your builder.
That said having VcPkg as a builder may not be the best way to implement.
You might be better off with a PseudoBuilder.

I'll add some comments in the PR when I get some time to do a thorough
review.

On Sun, Sep 11, 2022 at 6:08 PM Ryan Saunders  wrote:

> Hi guys,
>
> While adding some unit tests to my VCPkg builder, I thought to try the
> "list" case, where someone does (e.g.) "env.VCPkg(["openjpeg", "glut"])" to
> install a list of packages. I was surprised to discover that this doesn't
> work...my source type's target_from_source method only gets called for the
> first item in the list, and the subsequent source nodes get dropped in the
> trash can, with no corresponding "target" nodes created for them.
>
> I tracked the issue down to this code:
> def _create_nodes(self, env, target = None, source = None):
> """Create and return lists of target and source nodes.
> """
> src_suf = self.get_src_suffix(env)
>
> target_factory = env.get_factory(self.target_factory)
> source_factory = env.get_factory(self.source_factory)
>
> source = self._adjustixes(source, None, src_suf)
> slist = env.arg2nodes(source, source_factory)
>
> pre = self.get_prefix(env, slist)
> suf = self.get_suffix(env, slist)
>
> *if target is None:*
> *try:*
> *t_from_s = slist[0].target_from_source*
> *except AttributeError:*
> *raise UserError("Do not know how to create a target from
> source `%s'" % slist[0])*
> *except IndexError:*
> *tlist = []*
> *else:*
> *splitext = lambda S: self.splitext(S,env)*
> *tlist = [ t_from_s(pre, suf, splitext) ]*
>
> I think this last bit ought to be:
> *if target is None:*
> *tlist = []*
> *for s in slist:*
> *try:*
> *t_from_s = s.target_from_source*
> *except AttributeError:*
> *raise UserError("Do not know how to create a target
> from source `%s'" % s)*
> *else:*
> *splitext = lambda S: self.splitext(S,env)*
> *tlist += [ t_from_s(pre, suf, splitext) ]*
>
> Does anyone know why this code is the way it is? Fixing this code seems a
> tiny bit scary, since it's so fundamental... Then again, it seems
> fundamentally broken.
>
> If I were to fix this, where would the best spot be for the appropriate
> unit test? Any special considerations I should be aware of?
>
> R
>
> Sent with Proton Mail  secure email.
> ___
> 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] SCons 4.4.0 Released

[Bill Deegan]

A new SCons release, 4.4.0, is now available
on the SCons download page:

  https://scons.org/pages/download.html

Here is a summary of the changes since 4.3.0:

NOTE: If you build with Python 3.10.0 and then rebuild with 3.10.1 (or
higher), you may
  see unexpected rebuilds. This is due to Python internals changing
which changed
  the signature of a Python Action Function.


NEW FUNCTIONALITY
-

- Added MSVC_USE_SCRIPT_ARGS Environment variable which specifies command
line arguments
  to pass to the script specified by MSVC_USE_SCRIPT.
- Added Configure.CheckMember() checker to check if struct/class has the
specified member.
- Added SHELL_ENV_GENERATORS construction variable. This variable should be
set to a list
  (or an iterable) which contains functions to be called in order
  when constructing the execution environment (Generally this is the shell
environment
  variables). This allows the user to customize how (for example) PATH is
constructed.
  Note that these are called for every build command run by SCons. It could
have considerable
  performance impact if not used carefully.
- Added MSVC_USE_SETTINGS construction variable to pass a dictionary to
configure the msvc compiler
  system environment as an alternative to bypassing Visual Studio
autodetection entirely.
- Added MSVC_SDK_VERSION construction variable which allows building with a
specific Microsoft
  SDK version. This variable is used with the msvc batch file determined
via autodetection. Refer
  to the documentation for additional requirements and validation details.
- Added MSVC_TOOLSET_VERSION construction variable which allows building
with a specific toolset
  version. This variable is used with the msvc batch file determined via
autodetection.  This
  variable does not affect the autodetection and selection of msvc
instances. The toolset version
  is applied after an msvc instance is selected. This could be the default
version of msvc. Refer
  to the documentation for additional requirements and validation details.
Addresses issue #3265,
  issue #3664, and pull request #4149.
- Added MSVC_SPECTRE_LIBS construction variable which allows building with
spectre-mitigated
  Visual C++ libraries. This variable is used with the msvc batch file
determined via autodetection.
  Refer to the documentation for additional requirements and validation
details.
- Added MSVC_SCRIPT_ARGS construction variable which specifies command line
arguments that are
  passed to the msvc batch file determined via autodetection.  Refer to the
documentation for
  additional requirements and validation details.  Addresses enhancement
issue #4106.
- Ninja: Added new alias "shutdown-ninja-scons-daemon" to allow ninja to
shutdown the daemon.
  Also added cleanup to test framework to kill ninja scons daemons and
clean ip daemon logs.
  NOTE: Test for this requires python psutil module. It will be skipped if
not present.
- Ninja: Added command line variable NINJA_CMD_ARGS that allows to pass
through ninja command line args.
  This can also be set in your Environment().
- Added a global policy setting and an environment construction variable
for specifying the
  action to be taken when an msvc request cannot be satisfied. The
available options are "error",
  "exception", "warning", "warn", "ignore", and "suppress".  The global
policy variable may be
  set and retrieved via the functions msvc_set_notfound_policy and
msvc_get_notfound_policy,
  respectively.  These two methods may be imported from
SCons.Tool.MSCommon. The environment
  construction variable is MSVC_NOTFOUND_POLICY.  When defined, the
environment construction
  variable overrides the global policy setting for a given environment.
When the active policy
  is "error" or "exception", an MSVCVersionNotFound exception is raised.
When the active policy
  is "warning" or "warn", a VisualCMissingWarning warning is issued and the
constructed
  environment is likely incomplete. When the active policy is "ignore" or
"suppress", no action
  is taken and the constructed environment is likely incomplete.  As
implemented, the default
  global policy is "warning".  The ability to set the global policy via an
SCons command-line
  option may be added in a future enhancement.
- Added a global policy setting and an environment construction variable
for specifying the
  action to be taken when msvc script errors are detected. The available
options are "error",
  "exception", "warning", "warn", "ignore", and "suppress".  The global
policy variable may be
  set and retrieved via the functions msvc_set_scripterror_policy and
msvc_get_scripterror_policy,
  respectively.  These two methods may be imported from
SCons.Tool.MSCommon. The environment
  construction variable is MSVC_SCRIPTERROR_POLICY.  When defined, the
environment construction
  variable overrides the global policy setting for a given environment.
When the active policy
  is "error" or "exception", an MSVCScriptExecutionError exception is

[Scons-dev] SCons 4.3.0 released

[Bill Deegan]

A new SCons release, 4.3.0, is now available
on the SCons download page:

  https://scons.org/pages/download.html


NOTE: 4.3.0 now requires Python 3.6.0 and above. Python 3.5.x is no longer
supported

Here is a summary of the changes since 4.2.0:

NEW FUNCTIONALITY
-

- Ninja - Added ninja API 'NINJA_FORCE_SCONS_BUILD' to force a node to
callback to scons.
- Add support for Visual Studio 2022.

DEPRECATED FUNCTIONALITY


- The qt tool, which targets Qt version 3, is deprecated. Qt3 has been
unsupported by
  upstream for many years.  Qt4 and Qt5 tools are available from
scons-contrib.

CHANGED/ENHANCED EXISTING FUNCTIONALITY
---

- Ninja - Expanded ninja Mkdir to also support Mkdir actions.
- Further PCH updates. It's now recommended that env['PCH'] should always
be a File node.
  Either via return value from env.PCH() or by explicitly using
File('StdAfx.pch').
- Change SCons.Platform.win32.get_architecture() to return
platform.platform() when run in an
  environment where neither: PROCESSOR_ARCHITEW6432 nor
PROCESSOR_ARCHITECTURE is set.
  This should fix platform tests which started failing when
HOST_OS/HOST_ARCH changes
  introduced by Aaron Franke (listed below) were merged.
- The Java tool now accepts more versions (up to 17.0), and is better
  able to detect the many builds of OpenJDK available since it became
  designated the reference Java implementation.

FIXES
-

- Fix reproducible builds. Restore logic respecting SOURCE_DATE_EPOCH when
set.
- Small fix to ensure CLVar default value is an empty list.
  See MongoDB bug report: https://jira.mongodb.org/browse/SERVER-59656
  Code contributed by MongoDB.
- Ninja - Fix ninja tool to never use for_sig substitution because ninja
does not use signatures. This
  issue affected CommandGeneratorAction function actions specifically.
- Fix PCH not being evaluated by subst() where necessary.
- Fix issue #4021.  Change the way subst() is used in Textfile() to not
evaluate '$$(' -> '$',
  but instead it should yield '$('.
- Ninja - Fix command line escaping for ninja dollar sign escape. Without
escaping ninja properly,
- Fix MSVS tests (vs-N.N-exec.py) for MSVS 6.0, 7.0, and 7.1 (import
missing module).
- Fix command line escaping for ninja dollar sign escape. Without escaping
ninja properly,
  the ninja file scons regenerate and callback invocations will lose the $
characters used in
  the scons command line which ninja uses itself for escaping. For Example:
  scons BUILD=xyz OTHERVAR=$BUILD
  Prior to this fix, it would cause ninja to fail to escape the dollar
sign, leading to the
  single dollar sign being used as a ninja escape character in the ninja
file.
- Ninja - Fixed an issue where if you control-c and/or killed ninja while
it was running scons to regenerate
  build.ninja you would end up with no build.ninja file and have to rerun
scons from scratch.
  Code contributed by MongoDB.

DEVELOPMENT
---

- Added --no-ignore-skips to runtest.py. Changed default to ignore skips
when setting
  runtest.py's exit status. Previously would exit 2 if any tests were
skipped.
  Now will only exit 2 if user specifies --no-ignore-skips and some tests
were skipped.

Thanks to the following contributors listed below for their contributions
to this release.
==
.. code-block:: text

git shortlog --no-merges -ns 4.2.0..HEAD
47  Mats Wichmann
46  William Deegan
14  Jacob Cassagnol
11  Daniel Moody
 8  Ryan Egesdahl
 5  Joseph Brill
 4  Omar Polo
 2  Brian Quistorff
 1  Aaron Franke
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] SCons 4.2.0 Released

[Bill Deegan]

A new SCons release, 4.2.0, is now available
on the SCons download page:

  https://scons.org/pages/download.html


Here is a summary of the changes since 4.1.0:

NOTE: The 4.2.0 Release of SCons will deprecate Python 3.5 Support. Python
3.5 support will be dropped in the next major release.


NEW FUNCTIONALITY
-

- Add support for the
(TARGET,SOURCE,TARGETS,SOURCES,CHANGED_TARGETS,CHANGED_SOURCES}.relpath
property.
  This will provide a path relative to the top of the build tree (where
the SConstruct is located)
  Fixes #396
- Added --experimental flag, to enable various experimental
features/tools.  You can specify
  'all', 'none', or any combination of available experimental features.
- Added affect_signature flag to  _concat function.  If set to False,
it will prepend and append $( and $).
  That way the various Environment variables can use that rather than
"$( _concat(...) $)".


DEPRECATED FUNCTIONALITY

- Deprecate Python 3.5 as a supported version.


CHANGED/ENHANCED EXISTING FUNCTIONALITY
---

- SCons now supports the command-line parameter `--hash-format` to
override the default
  hash format that SCons uses. It can also be set via
`SetOption('hash_format')`. Supported
  values are: `md5`, `sha1`, and `sha256`. For all hash formats other
than
  the default of `md5`, the SConsign database will include the name of
the hash format.
  For example, `--hash-format=sha256` will create a SConsign with name
  `.sconsign_sha256.dblite.`.
- Improve Subst()'s logic to check for proper callable function or
class's argument list.
  It will now allow callables with expected args, and any extra args as
long as they
  have default arguments. Additionally functions with no defaults for
extra arguments
  as long as they are set using functools.partial to create a new
callable which set them.
- Internal has_key methods removed from SCons' dictionary-like objects
  SubstitutionEnvironment and OverrideEnvironment - in other words,
  an env - to match Python 3 which no longer has dict.has_key.
- Removed long-deprecated construction variables PDFCOM,
WIN32_INSERT_DEF,
  WIN32DEFPREFIX, WIN32DEFSUFFIX, WIN32EXPPREFIX, WIN32EXPSUFFIX.
  All have been replaced by other names since at least 1.0.
- Added CACHEDIR_CLASS construction variable and expanded CacheDir
method args
  to support SCons invoking CacheDir derived classes for CacheDir
customization.
  Moved copy_from_cache attribute from the Environment class to
CacheDir class.
  Code contributed by MongoDB.
- Update BuildTask to pass all targets to the progress object fixing an
issue
  where multi-target build nodes only got the first target passed to
the progress
  object.
- Change SConscript() missing SConscript behavior - if must_exist=False,
  the warning is suppressed.


FIXES
-

- The command-line parameter `--md5-chunksize` is now deprecated. Use
`--hash-chunksize`
  instead.
- Fix Issue #3906 - `IMPLICIT_COMMAND_DEPENDENCIES` was not properly
disabled when
  set to any string value (For example ['none','false','no','off'])
  Also previously 'All' wouldn't have the desired affect.
- DocbookXslt tool: The XSLT stylesheet file is now initialized to an
env.File() Node,
  such that dependencies work correctly in hierarchical builds (eg when
using
  DocbookXslt in SConscript('subdir/SConscript') context.
- The Install builder will now set the writable mode on the file(s) it
  copies. This restores the (previously undocumented) SCons behavior
  that regressed as of 4.0.0.
- Fix issue #3790: Generators in CPPDEFINES now have access to
populated source
  and target lists
- Fix a potential race condition in shared cache environments where the
permissions are
  not writeable for a moment after the file has been renamed and other
builds (users) will copy
  it out of the cacheSmall reorganization of logic to copy files from
cachedir. Moved CacheDir
  writeable permission code for copy to cache behind the atomic rename
operation.
- Fixed intermediate and and multi target nodes generated from SConf
tests not being marked
  as is_conftest().



Thanks to the following contributors listed below for their contributions
to this release.
==
.. code-block:: text

git shortlog --no-merges -ns 4.1.0..HEAD
   177  William Deegan
   101  Daniel Moody
95  Mats Wichmann
25  Adam Gross
 4  greenbender
 4  Daniel
 4  Henrik Maier
 4  Mathew Robinson
 3  Andrew Morrow
 3  Ivan Kravets
 3  Dillan Mills
 1  WholesomeIsland
 1  dependabot[bot]
 1  djh
 1  Joseph Brill

Re: [Scons-dev] Py 3.5 support.. How important is it?

[Bill Deegan]

Jonathon,

K. Thanks for the info.
Do you know when Debian 9 EOLs?

-Bill

On Tue, Jan 12, 2021 at 4:41 AM Jonathon Reinhart <
jonathon.reinh...@gmail.com> wrote:

> No, only Python 3.5 is in the standard repo. As far as I know, the only
> way to install something newer is to compile Python from source (an
> alternate install).
>
> On Tue, Jan 12, 2021, 00:05 Bill Deegan  wrote:
>
>> Jonathon,
>>
>> Are there py 3.6 or newer python packages for Debian 9 in the standard
>> repo?
>> Or is it a special add on.
>>
>> -Bill
>>
>> On Mon, Jan 11, 2021 at 8:32 PM Jonathon Reinhart <
>> jonathon.reinh...@gmail.com> wrote:
>>
>>> Debian 9 is still supported, and runs Python 3.5:
>>> https://wiki.debian.org/Python
>>>
>>> But, that can be worked around by either adding a newer version of
>>> Python, or holding back the SCons version.
>>>
>>> On Mon, Jan 11, 2021, 23:06 Bill Deegan 
>>> wrote:
>>>
>>>> Greetings,
>>>>
>>>> Since Py 3.5 is EOL'd we're considering moving the floor version for
>>>> SCons to 3.6.
>>>>
>>>> Please comment if 3.5 is still important to you and why
>>>>
>>>> Thanks,
>>>> Bill
>>>> SCons Project Co-manager
>>>> ___
>>>> Scons-dev mailing list
>>>> Scons-dev@scons.org
>>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>>
>>> ___
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Py 3.5 support.. How important is it?

[Bill Deegan]

Jonathon,

Are there py 3.6 or newer python packages for Debian 9 in the standard repo?
Or is it a special add on.

-Bill

On Mon, Jan 11, 2021 at 8:32 PM Jonathon Reinhart <
jonathon.reinh...@gmail.com> wrote:

> Debian 9 is still supported, and runs Python 3.5:
> https://wiki.debian.org/Python
>
> But, that can be worked around by either adding a newer version of Python,
> or holding back the SCons version.
>
> On Mon, Jan 11, 2021, 23:06 Bill Deegan  wrote:
>
>> Greetings,
>>
>> Since Py 3.5 is EOL'd we're considering moving the floor version for
>> SCons to 3.6.
>>
>> Please comment if 3.5 is still important to you and why
>>
>> Thanks,
>> Bill
>> SCons Project Co-manager
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Py 3.5 support.. How important is it?

[Bill Deegan]

Greetings,

Since Py 3.5 is EOL'd we're considering moving the floor version for SCons
to 3.6.

Please comment if 3.5 is still important to you and why

Thanks,
Bill
SCons Project Co-manager
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] fix for partial reads from cache

[Bill Deegan]

Any chance you can make a pull request for this?

On Tue, Oct 27, 2020 at 1:02 PM Raven Kopelman 
wrote:

> Looks like attachment is not easy to access; here's plaintext patch
>
> diff -ru -x '*.pyc' SCons.orig/CacheDir.py
> /usr/local/lib/python2.7/dist-packages/scons/SCons/CacheDir.py
> --- SCons.orig/CacheDir.py 2020-10-23 16:12:44.773349285 -0700
> +++ /usr/local/lib/python2.7/dist-packages/scons/SCons/CacheDir.py
> 2020-10-23 16:19:48.676570382 -0700
> @@ -56,7 +56,20 @@
>  if fs.islink(cachefile):
>  fs.symlink(fs.readlink(cachefile), t.get_internal_path())
>  else:
> -env.copy_from_cache(cachefile, t.get_internal_path())
> +try:
> +env.copy_from_cache(cachefile, t.get_internal_path())
> +except:
> +try:
> +# In case file was partially retrieved (and now
> corrupt)
> +# delete it to avoid poisoning commands like 'ar' that
> +# read from the initial state of the file they are
> writing
> +# to.
> +t.fs.unlink(t.get_internal_path())
> +except:
> +pass
> +
> +raise
> +
>  try:
>  os.utime(cachefile, None)
>  except OSError:
> @@ -71,7 +84,7 @@
>  cd = env.get_CacheDir()
>  cachedir, cachefile = cd.cachepath(t)
>  if t.fs.exists(cachefile):
> -return "Retrieved `%s' from cache" % t.get_internal_path()
> +return "Retrieving `%s' from cache" % t.get_internal_path()
>  return None
>
>  CacheRetrieve = SCons.Action.Action(CacheRetrieveFunc,
> CacheRetrieveString)
> diff -ru -x '*.pyc' SCons.orig/Taskmaster.py
> /usr/local/lib/python2.7/dist-packages/scons/SCons/Taskmaster.py
> --- SCons.orig/Taskmaster.py 2020-10-23 16:12:44.785349378 -0700
> +++ /usr/local/lib/python2.7/dist-packages/scons/SCons/Taskmaster.py
> 2020-10-23 15:55:41.521758762 -0700
> @@ -243,10 +243,13 @@
>  cached_targets.append(t)
>  if len(cached_targets) < len(self.targets):
>  # Remove targets before building. It's possible that we
> -# partially retrieved targets from the cache, leaving
> -# them in read-only mode. That might cause the command
> +# retrieved a subset of targets from the cache, leaving
> +# them in an inconsistent state. That might cause the
> command
>  # to fail.
>  #
> +# Note that retrieve_from_cache() ensures no single
> target can
> +# be partially retrieved (file left in corrupt state).
> +#
>  for t in cached_targets:
>  try:
>  t.fs.unlink(t.get_internal_path())
>
> --
> *Raven Kopelman* | Team Lead, Senior Developer
>
> Safe Software Inc.
> *T* 604.501.9985 x 331 | *F* 604.501.9965
> raven.kopel...@safe.com | www.safe.com
>
> 
>
>
> On Tue, Oct 27, 2020 at 1:00 PM Raven Kopelman 
> wrote:
>
>> Hi scons devs,
>>
>> Here's a fix to clean up reads from the cache that fail part way
>> through.  Absolutely experienced by us in production (non-local shared
>> cache).  This may be what my last UUID temp name fix was really trying to
>> address, but I can imagine edge cases that the UUID fix could still improve.
>>
>> This could also have been fixed in Taskmaster.py near my comment change,
>> but the reasons for cleanup seemed different enough to keep them distinct.
>>
>> Also cleaned up the logged message tense, as message is logged before the
>> cache retrieval begins.
>>
>> Thanks!
>> --
>> *Raven Kopelman* | Team Lead, Senior Developer
>>
>> Safe Software Inc.
>> *T* 604.501.9985 x 331 | *F* 604.501.9965
>> raven.kopel...@safe.com | www.safe.com
>>
>> 
>>
> ___
> 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 copyto /path/to/project

[Bill Deegan]

no more likely
scons SCONS_LOCAL_DIR=/path/to/where/I/want/it scons-local

On Fri, Sep 11, 2020 at 2:50 AM anatoly techtonik 
wrote:

> Do you mean the command will becomes `scons scons-local /path/to/project`?
>
> I still haven't found the way to pass the location to either command.
>
> On Tue, Sep 8, 2020 at 6:25 PM Bill Deegan 
> wrote:
> >
> > This is probably the wrong way to go about this.
> > I'd rather just allow passing in the location to build the scons-local
> and not copy it after it's been constructed.
> > Seems a much simpler method.
> >
> >
> > On Mon, Sep 7, 2020 at 1:03 PM anatoly techtonik 
> wrote:
> >>
> >> On Mon, Sep 7, 2020 at 6:13 PM Bill Deegan 
> wrote:
> >> >
> >> > yes. it belongs in the users mailing list.
> >> > It's about using scons.
> >> > (whether that's about installing scons it doesn't matter)
> >> >
> >> > So you're proposing to add this logic into SCons' own SConstruct?
> >>
> >> Exactly. PR message asked to discuss it first.
> >>
> >> > On Mon, Sep 7, 2020 at 11:01 AM anatoly techtonik <
> techto...@gmail.com> wrote:
> >> >>
> >> >> On Sun, Sep 6, 2020 at 12:23 AM Bill Deegan <
> b...@baddogconsulting.com> wrote:
> >> >> >
> >> >> > probably should be on the users mailing list.
> >> >>
> >> >> Not really. I want to add a feature to copy scons-local to another
> >> >> project directory without zipping and unzipping it.
> >> >>
> >> >> > Go take a look at the manpage.
> >> >> > I think env.Install() is what you want..
> >> >>
> >> >> https://scons.org/doc/4.0.1/HTML/scons-user/ch11.html
> >> >> Looks like installation is just a copy. Or is there something I
> missed?
> >> >>
> >> >> > On Sat, Sep 5, 2020 at 10:33 AM anatoly techtonik <
> techto...@gmail.com> wrote:
> >> >> >>
> >> >> >> Hi.
> >> >> >>
> >> >> >> Is it possible to create a build command that will copy
> >> >> >> SCons local to the target directory?
> >> >> >>
> >> >> >> SCons/ -> /path/to/project/SCons/
> >> >> >> scripts/scons.py -> /path/to/project/scons
> >> >> >>
> >> >> >> I haven't used SCons for a while and I don't remember
> >> >> >> how to create phony target "copyto" and handle path
> >> >> >> parameter to it.
> >> >> >> --
> >> >> >> anatoly t.
> >> >> >> ___
> >> >> >> Scons-dev mailing list
> >> >> >> Scons-dev@scons.org
> >> >> >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >> >> >
> >> >> > ___
> >> >> > Scons-dev mailing list
> >> >> > Scons-dev@scons.org
> >> >> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> anatoly t.
> >> >> ___
> >> >> Scons-dev mailing list
> >> >> Scons-dev@scons.org
> >> >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >> >
> >> > ___
> >> > Scons-dev mailing list
> >> > Scons-dev@scons.org
> >> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >>
> >>
> >>
> >> --
> >> anatoly t.
> >> ___
> >> Scons-dev mailing list
> >> Scons-dev@scons.org
> >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> --
> anatoly t.
> ___
> 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 copyto /path/to/project

[Bill Deegan]

This is probably the wrong way to go about this.
I'd rather just allow passing in the location to build the scons-local and
not copy it after it's been constructed.
Seems a much simpler method.


On Mon, Sep 7, 2020 at 1:03 PM anatoly techtonik 
wrote:

> On Mon, Sep 7, 2020 at 6:13 PM Bill Deegan 
> wrote:
> >
> > yes. it belongs in the users mailing list.
> > It's about using scons.
> > (whether that's about installing scons it doesn't matter)
> >
> > So you're proposing to add this logic into SCons' own SConstruct?
>
> Exactly. PR message asked to discuss it first.
>
> > On Mon, Sep 7, 2020 at 11:01 AM anatoly techtonik 
> wrote:
> >>
> >> On Sun, Sep 6, 2020 at 12:23 AM Bill Deegan 
> wrote:
> >> >
> >> > probably should be on the users mailing list.
> >>
> >> Not really. I want to add a feature to copy scons-local to another
> >> project directory without zipping and unzipping it.
> >>
> >> > Go take a look at the manpage.
> >> > I think env.Install() is what you want..
> >>
> >> https://scons.org/doc/4.0.1/HTML/scons-user/ch11.html
> >> Looks like installation is just a copy. Or is there something I missed?
> >>
> >> > On Sat, Sep 5, 2020 at 10:33 AM anatoly techtonik <
> techto...@gmail.com> wrote:
> >> >>
> >> >> Hi.
> >> >>
> >> >> Is it possible to create a build command that will copy
> >> >> SCons local to the target directory?
> >> >>
> >> >> SCons/ -> /path/to/project/SCons/
> >> >> scripts/scons.py -> /path/to/project/scons
> >> >>
> >> >> I haven't used SCons for a while and I don't remember
> >> >> how to create phony target "copyto" and handle path
> >> >> parameter to it.
> >> >> --
> >> >> anatoly t.
> >> >> ___
> >> >> Scons-dev mailing list
> >> >> Scons-dev@scons.org
> >> >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >> >
> >> > ___
> >> > Scons-dev mailing list
> >> > Scons-dev@scons.org
> >> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >>
> >>
> >>
> >> --
> >> anatoly t.
> >> ___
> >> Scons-dev mailing list
> >> Scons-dev@scons.org
> >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> --
> anatoly t.
> ___
> 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 copyto /path/to/project

[Bill Deegan]

It's scons use of scons, not internal to scons.

On Mon, Sep 7, 2020 at 12:39 PM Bill Deegan 
wrote:

> As I said. Users mailing list.
>
>
> On Mon, Sep 7, 2020 at 11:11 AM anatoly techtonik 
> wrote:
>
>> But it will be be a patch for
>> https://github.com/SCons/scons/blob/master/SConstruct
>>
>> On Mon, Sep 7, 2020 at 6:02 PM Bill Deegan 
>> wrote:
>> >
>> > THis belongs in scons-user mailing list. Moving it there.
>> >
>> > On Mon, Sep 7, 2020 at 10:33 AM anatoly techtonik 
>> wrote:
>> >>
>> >> On Sun, Sep 6, 2020 at 7:12 PM Mats Wichmann  wrote:
>> >> > >
>> >> > > Is it possible to create a build command that will copy
>> >> > > SCons local to the target directory?
>> >> > >
>> >> > > SCons/ -> /path/to/project/SCons/
>> >> > > scripts/scons.py -> /path/to/project/scons
>> >> > >
>> >> > > I haven't used SCons for a while and I don't remember
>> >> > > how to create phony target "copyto" and handle path
>> >> > > parameter to it.
>> >> >
>> >> > Phony targets are Alias.
>> >> > Copying stuff usually involves some combination of Install and
>> Default.
>> >> >
>> >> > If that's what you are asking...
>> >>
>> >> Yup, thanks. I created a target that copies `scripts/scons.py` to
>> `scons`,
>> >> which is invoked as `scons copyto`:
>> >>
>> >> Command('scons', [], Copy('$TARGET', 'scripts/scons.py'))
>> >> Alias('copyto', 'scons')
>> >>
>> >> Now how to parse `/path/to/project` param to `copyto`?
>> >> --
>> >> anatoly t.
>> >> ___
>> >> Scons-dev mailing list
>> >> Scons-dev@scons.org
>> >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>> >
>> > ___
>> > Scons-dev mailing list
>> > Scons-dev@scons.org
>> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>>
>>
>> --
>> anatoly t.
>> ___
>> 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 copyto /path/to/project

[Bill Deegan]

As I said. Users mailing list.


On Mon, Sep 7, 2020 at 11:11 AM anatoly techtonik 
wrote:

> But it will be be a patch for
> https://github.com/SCons/scons/blob/master/SConstruct
>
> On Mon, Sep 7, 2020 at 6:02 PM Bill Deegan 
> wrote:
> >
> > THis belongs in scons-user mailing list. Moving it there.
> >
> > On Mon, Sep 7, 2020 at 10:33 AM anatoly techtonik 
> wrote:
> >>
> >> On Sun, Sep 6, 2020 at 7:12 PM Mats Wichmann  wrote:
> >> > >
> >> > > Is it possible to create a build command that will copy
> >> > > SCons local to the target directory?
> >> > >
> >> > > SCons/ -> /path/to/project/SCons/
> >> > > scripts/scons.py -> /path/to/project/scons
> >> > >
> >> > > I haven't used SCons for a while and I don't remember
> >> > > how to create phony target "copyto" and handle path
> >> > > parameter to it.
> >> >
> >> > Phony targets are Alias.
> >> > Copying stuff usually involves some combination of Install and
> Default.
> >> >
> >> > If that's what you are asking...
> >>
> >> Yup, thanks. I created a target that copies `scripts/scons.py` to
> `scons`,
> >> which is invoked as `scons copyto`:
> >>
> >> Command('scons', [], Copy('$TARGET', 'scripts/scons.py'))
> >> Alias('copyto', 'scons')
> >>
> >> Now how to parse `/path/to/project` param to `copyto`?
> >> --
> >> anatoly t.
> >> ___
> >> Scons-dev mailing list
> >> Scons-dev@scons.org
> >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> --
> anatoly t.
> ___
> 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 copyto /path/to/project

[Bill Deegan]

yes. it belongs in the users mailing list.
It's about using scons.
(whether that's about installing scons it doesn't matter)

So you're proposing to add this logic into SCons' own SConstruct?

On Mon, Sep 7, 2020 at 11:01 AM anatoly techtonik 
wrote:

> On Sun, Sep 6, 2020 at 12:23 AM Bill Deegan 
> wrote:
> >
> > probably should be on the users mailing list.
>
> Not really. I want to add a feature to copy scons-local to another
> project directory without zipping and unzipping it.
>
> > Go take a look at the manpage.
> > I think env.Install() is what you want..
>
> https://scons.org/doc/4.0.1/HTML/scons-user/ch11.html
> Looks like installation is just a copy. Or is there something I missed?
>
> > On Sat, Sep 5, 2020 at 10:33 AM anatoly techtonik 
> wrote:
> >>
> >> Hi.
> >>
> >> Is it possible to create a build command that will copy
> >> SCons local to the target directory?
> >>
> >> SCons/ -> /path/to/project/SCons/
> >> scripts/scons.py -> /path/to/project/scons
> >>
> >> I haven't used SCons for a while and I don't remember
> >> how to create phony target "copyto" and handle path
> >> parameter to it.
> >> --
> >> anatoly t.
> >> ___
> >> Scons-dev mailing list
> >> Scons-dev@scons.org
> >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> --
> anatoly t.
> ___
> 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 copyto /path/to/project

[Bill Deegan]

THis belongs in scons-user mailing list. Moving it there.

On Mon, Sep 7, 2020 at 10:33 AM anatoly techtonik 
wrote:

> On Sun, Sep 6, 2020 at 7:12 PM Mats Wichmann  wrote:
> > >
> > > Is it possible to create a build command that will copy
> > > SCons local to the target directory?
> > >
> > > SCons/ -> /path/to/project/SCons/
> > > scripts/scons.py -> /path/to/project/scons
> > >
> > > I haven't used SCons for a while and I don't remember
> > > how to create phony target "copyto" and handle path
> > > parameter to it.
> >
> > Phony targets are Alias.
> > Copying stuff usually involves some combination of Install and Default.
> >
> > If that's what you are asking...
>
> Yup, thanks. I created a target that copies `scripts/scons.py` to `scons`,
> which is invoked as `scons copyto`:
>
> Command('scons', [], Copy('$TARGET', 'scripts/scons.py'))
> Alias('copyto', 'scons')
>
> Now how to parse `/path/to/project` param to `copyto`?
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] scons copyto /path/to/project

[Bill Deegan]

probably should be on the users mailing list.

Go take a look at the manpage.
I think env.Install() is what you want..

On Sat, Sep 5, 2020 at 10:33 AM anatoly techtonik 
wrote:

> Hi.
>
> Is it possible to create a build command that will copy
> SCons local to the target directory?
>
> SCons/ -> /path/to/project/SCons/
> scripts/scons.py -> /path/to/project/scons
>
> I haven't used SCons for a while and I don't remember
> how to create phony target "copyto" and handle path
> parameter to it.
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] MSVC 2017+ Toolset Support

[Bill Deegan]

So to summarize the only (possible) difference between pro,ent,community
would be in whatever optional and/or updated components were installed for
each?

So selecting one over the other would be useful just to use those
differences (optional/selected tools/components available via the visual
studio installer).

Does anyone have pro, enterprise, and community (or more than just one of
those versions installed) that could do a dump of vswhere output to answer
the question of ordering?

Note that vswhere's source code is on github...



On Fri, Aug 14, 2020 at 7:40 AM Joseph Brill 
wrote:

> On Tue, Aug 11, 2020 at 10:52 PM Jason Kenny  wrote:
>
>> Just to chime in.. my understanding of the vc compiler is that it is the
>> same for all these cases. The community, profession and enterprise is about
>> extra paid features of the IDE. While these are all side by side
>> installable.. the code you build, as I understand, is the same. For me at
>> least I don’t see what value exists yet in selecting license level values
>> of the MSVS
>>
>
> *All – please respond with any corrections and clarifications if anything
> below is inaccurate or misleading. *
>
>
>
> In general, this assessment is accurate.  With respect to the current
> SCons implementation however, an important qualification is necessary and
> is illustrated below.
>
>
>
> There is a potentially rare problem that only manifests itself when
> multiple product instances (i.e., Enterprise, Professional, Community, and
> Build Tools) of the same version are installed due to the current instance
> selection implementation for 2017 and 2019 based on the vswhere tool.
>
>
>
> Given two or more installations of Enterprise, Professional, and
> Community:  the expected build *behavior is the same given that the
> installed features and target toolsets are the same*.
>
>
>
> Given two or more installations of Enterprise, Professional, and
> Community:  the expected build behavior *can be different if the
> installed features or target toolsets are different*.  Herein lies the
> rub.
>
>
>
> Currently, the selected MSVS instance is independent of the required
> host/target architecture and toolset for the build.  With multiple
> instances of the same product installed, it is possible an installed
> instance is selected that does not fulfill the required features/toolsets
> despite the presence of installed instances that do fulfill the required
> features/toolsets.
>
>
>
> Consider the following installations of MSVS 2019:
>
> - MSVS 2019 Enterprise: only toolsets targeting windows x64/x86
>
> - MSVS 2019 Community: only toolsets targeting arm/arm64.
>
>
>
> In this case:
>
> - If 2019 Enterprise is always returned: arm/arm64 builds would fail
>
> - If 2019 Community is always returned: x64/x86 builds would fail
>
>
>
> The Visual Studio Installer offers a smorgasbord of independently selected
> features (e.g., ATL, MFC), targets (e.g., arm, arm64), and toolsets.
> Toolsets can be identified by the folder layout and existence of
> tool binaries within an MSVS installation.  Features are likely difficult
> or impossible to identify.
>
>
>
> It could be possible that an end-user may not want to modify a
> corporate/IT supplied Enterprise instance or may be restricted from making
> changes.  In this case, installing the Community edition makes sense.  For
> example, x86/x64 software for work and arm/arm64 software for pleasure.
>
>
>
> Similar examples with “features” could apply as well: one instance might
> have ATL+MFC support installed while another instance does not.  In this
> case, there would be a problem if the instance without ATL+MFC were
> selected.
>
>
>
> Given multiple instances installed with the same products and features, it
> may be desirable to install updates (e.g., minor toolset updates) in one
> instance and test with that particular instance prior to propagating the
> same updates to the other instances.   While extremely rare, code
> generation bugs are possible in a minor toolset update. Reliance on
> “undocumented” features also can also be problematic when switching
> products and toolsets.  With a corporate/it managed instance, updates may
> be less frequent than a user-managed instance.
>
>
>
> Given two or more instances installed, it may be desirable to force a
> build using the same product type as a customer and/or a production build
> environment for purposes of verification and validation.
>
>
>
> If nothing else, it is useful for testing SCons J
>
>
>
> I am unaware of any documentation that describes the order in which
> vswhere would return instances of Enterprise, Professional, and Community
> if all three were present.  Alphabetical? Last installed to first
> installed?  License level?  I don't have access to licensed versions of the
> Enterprise and Professional products.
>
>
> With respect to the current SCons implementation, expansion of the
> user-defined product specification would be useful even without specific
> 

Re: [Scons-dev] MSVC 2017+ Toolset Support

[Bill Deegan]

To be clear, I'm not in favor of your proposed MSVC_VERSION regex
interpretation, so let's table any discussion of that as it's not relevant
to figuring out how to properly select a version of MSVC and toolset and
product type.

Am I grossly mistaken, or would separate variables as I've proposed above
also allow specifying as explicitly as the single string which needs to be
regex'd?


On Tue, Aug 11, 2020 at 9:24 AM Joseph Brill 
wrote:

> On Tue, Aug 11, 2020 at 11:51 AM Mats Wichmann  wrote:
>
>> To throw another spanner into the works, there are Visual Studio product
>> codes too, which are 16.X for 2019, 15.x for 2017 and 14.0 for 2015...
>>
>
> Nothing is straightforward with the microsoft version numbers.
>
> A mapping was necessary from the vswhere query results containing the MSVS
> version to the MSVC version number.  The explicitly supported component ids
> are listed by product as there are a quite a few component ids in which we
> are not interested.  And yes, one of the components that we are
> not-interested in caused a previous version to fail.
>
> And it looks like I have a typographical error to fix as well...
>
> # Vswhere query elements (reverse dictionaries computed during 
> intialization)# MSVS_MAJOR: MSVS installationVersion.split('.')[0] <-> to 
> _VCVER# Products: expected product components returned in vswhere query
> _MSVC_PRODUCTVERSION_COMPONENTIDS = {
> '14.2': {
> 'MSVS_MAJOR' : '16',
> 'Products'   : ['Enterprise', 'Professional', 'Community', 
> 'BuildTools']
> },
> '14.1': {
> 'MSVS_MAJOR' : '15',
> 'Products'   : ['Enterprise', 'Professional', 'Community', 
> 'BuildTools', _MSVC_COMPONENT_EXPRESS]
> },
>
> }
>
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] MSVC 2017+ Toolset Support

[Bill Deegan]

Can I end up with 14.1 installed in both a MSVC2017 and MSVC2019 install
(and of course also all  the flavors of MSVC, build tools, express,
community, enterprise), for a possible total of 8 separate installs? (or
some smaller non singular number?)

I'm not a fan of the more complicated syntax for MSVC_VERSION and would
rather split out the selection to either separate variables for product,
toolset, and product version and/or a callable which handles selection.
MSVC_VERSION -> sounds like after MSVC2017 defaults to latest installed
toolset unless you set toolset version
MSVC_PRODUCT_VERSION -> Enterprise, Professional, Community, Express, or
not set
MSVC_TOOLSET_VERSION  -> This may only apply for MSVC2017 or above (or
could be used if MSVC_VERSION is not set for MSVC < 2017, though that would
likely introduce confusion

MSVC_SELECTOR -> Callable (too allow more flexibility than static versions
above)

Otherwise you end up encoding the information in a string and then you have
to decode it.
Seems more complicated than necessary, and we don't have any other syntaxes
embedded in variables thus far.

I realize you have lots of time invested in your MSVC_VERSION
implementation you've explained, but the goal here is to be consistent with
expected behavior in the face of changed MSVC.

(And yes. I know.. "Foolish consistency is the hobgoblin of little minds",
but I think in this case it's not foolish)

Welcome feedback on above.




On Sun, Aug 9, 2020 at 2:50 PM Joseph Brill 
wrote:

> This email is an attempt to focus the discussion concerning support for
> MSVC toolsets moving forward in a rational, dispassionate discourse.
>
> I am advocating a minor shift in orientation or "world view" for MSVC 2017
> and later: the semantic transition from thinking of the msvc version as a
> product to thinking of the msvc version as a toolset.  This actually makes
> the implementation of toolset support easier.
>
> There is a working version of the support for toolsets at varying levels
> of precision that can be enabled and disabled.  The intent is that a
> command-line switch could be added to enable the toolset specific
> capabilities.  By default, the toolset specific capabilities would be
> disabled in which case the code behaves exactly like the current master.
> This would allow field testing and evaluation of the functionality in other
> environments and to easily test the differences between the current master
> and the toolset functionality.  The functional aspects are feature
> complete.  The working version is a product of more than one man-month of
> full-time development activity and the result of the third iteration of
> implementation strategy.
>
> Existing PR #3717 was closed and the branch renamed due in part to make it
> easier to identify and maintain for myself as I fear that I might be time
> limited in the near term and due in part to the existing discussion
> unraveling fairly quickly with dim prospects of inclusion moving forward.  
> Despite
> being closed, I recommend viewing the "documentation" (the PR text and the
> first comment) and the vc.py code difference in PR #3717.  At any time the
> PR request can be reopened.  I would need a git guru to walk me through
> associating the new branch name with the "old" PR.
>
> The implementation knocks an item or two off the internal vc.py TODO list
> such as a single vswhere query and processing the json results for all
> known installations.  Ranked toolset lists are constructed by host/target.
> The ranking takes into account the toolset version and product type.  A
> single toolset instance may be a member of multiple toolset lists.
> Expensive lookups are "runtime memoized/cached" so that they are only
> computed once.  While there is a fair amount of initialization, the
> processing burden is based on the number of products installed and the
> number of toolsets for each product.  Typical environments likely have a
> single product installation with a spartan number of different toolsets
> installed. There is nothing particularly "clever" done in the
> implementation and should not be a maintenance burden.  The bulk of the
> toolset support implementation follows the code in the existing master
> (i.e., the bottom of the file).  The modifications to support toolsets
> weighs in at approximately 1400 lines of code.
>
> Prior to MSVS 2017, there was a direct 1:1 mapping between the msvc
> *product* and the msvc *toolset*. The toolset might be upgraded in an
> update or service pack but there was no way to select a specific toolset as
> side-by-side installations were not supported.  That changed with the
> release of MSVC 2017 which allows multiple side-by-side toolset
> installations by target.  MSVC 2017 and later, can be viewed as *toolset* 
> oriented
> (i.e., a MSVC 2019 installation can be viewed as a container for 14.1X,
> 14.2X, and transparently the 14.0 toolsets).  Moving forward, I believe
> that it will be advantageous to change from 

Re: [Scons-dev] Question regarding variant_dirs and custom builders

[Bill Deegan]

This email belongs in scons-user, please respond there.

How are you using Variant dirs, via VariantDir() or via SConscript()'s
variant_dir?
Are you using duplicate=0 or duplicate=1

Please share whatever code you have so far.

In general the build shouldn't have to do anything at all.
It should be presented with the proper source files and targets, that it's
in a variant dir should be invisible.

On Fri, Jul 17, 2020 at 2:56 AM Bastian Reitemeier  wrote:

> Hi,
>
> I am trying to make a custom builder (with a custom emitter) that plays
> well when building in a variant_dir.
> I am having trouble understanding how a custom emitter deals with variant
> paths (or if it has to deal with it).
> Here is what I am trying to do: I have a source dir, and a separate
> variant_dir for building in.
> Let’s call them src/ and build/. I want to make a custom builder that
> given a source tarball at a path in src (lets say src/a/b/c.tar) extracts
> the archive to the same relative path in the variant_dir (build/a/b/).
> Currently I am simply using the tarfile.extractall standard library
> function.
> My questions are now:
> How do I make my builder “aware” of the variant dir? That is, how do I
> construct the path within the variant_dir to pass to extract_all(path=...)?
> How do the built-in Builders deal with this?
> When emitting the contents of the tarball as new_targets, what paths do I
> have to emit (relative to src. relative to build, absolute paths)?
> I managed to get a solution that extracts to the correct path (by
> (ab-)using the alter_targets method), but fails at deciding if the tarball
> needs re-extracting. Instead it just re-extracts it every time.
> Does the answer to these questions change when the variant dir is
> duplicate=0?
>
> Best Regards,
> Bastian
> ___
> 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] SCons 4.0.1 Released

[Bill Deegan]

  A new SCons release, 4.0.1, is now available
  on the SCons download page:

  https://scons.org/pages/download.html

  Here is a summary of the changes since 4.0.1:

  NEW FUNCTIONALITY

- Added Environment() variable TEMPFILEDIR which allows setting the
directory which temp
  files createdby TEMPFILEMUNGE are created in.

  DEPRECATED FUNCTIONALITY

- N/A

  CHANGED/ENHANCED EXISTING FUNCTIONALITY

- N/A

  FIXES

- Fix fortran tools to set SHFORTRAN variables to $FORTRAN, similarly
SHF77, SHF90, SHF95,
  SHF03 and SHF08 will default to the variables $F77, $F90, $F95, $F03
and $F08 respectively.
  If you were depending on changing the value of FORTRAN (or
$F[0-9][0-9]) having no effect
  on the value of SHFORTRAN, this change will break that.   The values
of FORTRAN, F77, F90,
  F95, F03, F08 and SHFORTRAN, SHF77 (etc.) now are not overridden in
generate if alredy set
  by the user.
- Fix subprocess execution of 'lslpp' on AIX to produce text standard
i/o.
- Re-do the fix for suncxx tool (Oracle Studio compiler) now that only
Python 3 is supported,
  to avoid decoding errors.

  IMPROVEMENTS

- N/A

  PACKAGING

- N/A

  DOCUMENTATION

- N/A

  DEVELOPMENT

- N/A

  Thanks to the following contributors listed below for their contributions
to this release.

git shortlog --no-merges -ns 4.0.0..HEAD
12  William Deegan
 2  Rob Boehne
 1  Clemens Tolboom
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

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

[Bill Deegan]

Thanks!
Well at least there's an easy work around for now.

On Sun, Jul 5, 2020 at 7:30 AM Eric Fahlgren  wrote:

> Bill,
>
> Issue filed along with some further experiments.
> https://github.com/SCons/scons/issues/3736
>
> I vaguely remember playing with the case-sensitivity options in Windows on
> this machine years ago, so I tested everything on another machine where
> Windows is pristine, but no joy, same issue presented in the same manner
> there, too.
>
> Eric
>
> On Sat, Jul 4, 2020 at 9:48 PM Bill Deegan 
> wrote:
>
>> Eric,
>>
>> Try pip install SCons==4.0
>> Does that make a difference?
>>
>> Packaging has been completely rewritten for 4.0.0 so I'm not surprised
>> there's an issue or two in the field.
>> (the previous code was written before there was a pip... ;) and then
>> duct-taped and bailing wired.. so it needed a rewrite)
>>
>> Ahh. Interesting because windows is case insensitive..
>>
>> Please file an Issue.
>>
>> Hoping to take a break tomorrow and I'll look at it on monday.. unless
>> someone else feels like taking a wack at fixing that.. ;)
>>
>> -Bill
>>
>> On Sat, Jul 4, 2020 at 7:41 PM Eric Fahlgren 
>> wrote:
>>
>>> First, Bill and Mats and everyone else, thanks for your continued
>>> development of SCons!
>>>
>>> I ran into a strange, probably Windows-specific issue upon installing
>>> 4.0.0.  I simply did "pip install scons==4.0.0" without issue, but when I
>>> ran "scons some_target", I got this:
>>>
>>> Traceback (most recent call last):
>>>   File "c:\program files\python38\lib\runpy.py", line 194, in
>>> _run_module_as_main
>>> return _run_code(code, main_globals, None,
>>>   File "c:\program files\python38\lib\runpy.py", line 87, in _run_code
>>> exec(code, run_globals)
>>>   File "C:\Program Files\Python38\Scripts\scons.exe\__main__.py", line
>>> 4, in 
>>> SCons.Script.main()
>>> ModuleNotFoundError: No module named 'SCons'
>>>
>>> It turns out that pip didn't name the installation directory
>>> "site-packages/*SCons*", but rather all-lower-case "site-packages/
>>> *scons*" (as it was with 3.1.2), so none of the run commands, scripts
>>> or tools will load.  I did "pip uninstall -y scons", made sure
>>> Lib/site-packages was clean, reinstalled 4.0.0 and everything was fine.  It
>>> appears that pip is not removing the old installation completely and
>>> leaving the top-level directory there with improper character case, but
>>> only when it does an "install over old".  I reproduced this a couple times,
>>> reinstalling 3.1 and then 4.0 over it to confirm.
>>>
>>> On Sat, Jul 4, 2020 at 3:57 PM Bill Deegan 
>>> wrote:
>>>
>>>>   A new SCons release, 4.0.0, is now available
>>>>   on the SCons download page:
>>>>
>>>>   https://scons.org/pages/download.html
>>>>
>>>>   Here is a summary of the changes since 3.1.2:
>>>>
>>>>   NEW FUNCTIONALITY
>>>>
>>>> - Added support for scanning multiple entries in an action string if
>>>>   IMPLICIT_COMMAND_DEPENDENCIES is set to 2 or 'all'. This enables
>>>> more thorough
>>>>   action scanning where every item in each command line is scanned
>>>> to determine
>>>>   if it is a non-source and non-target path and added to the list
>>>> of implicit dependencies
>>>>   for the target.
>>>> - Added new module SCons.Scanner.Python to allow scanning .py files.
>>>> - Added support for explicitly passing a name when creating Value()
>>>> nodes. This may be useful
>>>>   when the value can't be converted to a string or if having a name
>>>> is otherwise desirable.
>>>> - Added a new flag called "linedraw" for the command line argument
>>>>  "--tree"
>>>>   that instructs scons to use single line drawing characters to
>>>> draw the dependency tree.
>>>> - Add CompilationDatabase() builder in compilation_db tool.
>>>> Contributed by MongoDB.
>>>>   Setting COMPILATIONDB_USE_ABSPATH to True|False controls whether
>>>> the files are absolute or relative
>>>>   paths.  Address Issue #3693 and #3694 found during development.
>>>> - Extended

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

[Bill Deegan]

Eric,

Try pip install SCons==4.0
Does that make a difference?

Packaging has been completely rewritten for 4.0.0 so I'm not surprised
there's an issue or two in the field.
(the previous code was written before there was a pip... ;) and then
duct-taped and bailing wired.. so it needed a rewrite)

Ahh. Interesting because windows is case insensitive..

Please file an Issue.

Hoping to take a break tomorrow and I'll look at it on monday.. unless
someone else feels like taking a wack at fixing that.. ;)

-Bill

On Sat, Jul 4, 2020 at 7:41 PM Eric Fahlgren  wrote:

> First, Bill and Mats and everyone else, thanks for your continued
> development of SCons!
>
> I ran into a strange, probably Windows-specific issue upon installing
> 4.0.0.  I simply did "pip install scons==4.0.0" without issue, but when I
> ran "scons some_target", I got this:
>
> Traceback (most recent call last):
>   File "c:\program files\python38\lib\runpy.py", line 194, in
> _run_module_as_main
> return _run_code(code, main_globals, None,
>   File "c:\program files\python38\lib\runpy.py", line 87, in _run_code
> exec(code, run_globals)
>   File "C:\Program Files\Python38\Scripts\scons.exe\__main__.py", line 4,
> in 
> SCons.Script.main()
> ModuleNotFoundError: No module named 'SCons'
>
> It turns out that pip didn't name the installation directory
> "site-packages/*SCons*", but rather all-lower-case "site-packages/*scons*"
> (as it was with 3.1.2), so none of the run commands, scripts or tools will
> load.  I did "pip uninstall -y scons", made sure Lib/site-packages was
> clean, reinstalled 4.0.0 and everything was fine.  It appears that pip is
> not removing the old installation completely and leaving the top-level
> directory there with improper character case, but only when it does an
> "install over old".  I reproduced this a couple times, reinstalling 3.1 and
> then 4.0 over it to confirm.
>
> On Sat, Jul 4, 2020 at 3:57 PM Bill Deegan 
> wrote:
>
>>   A new SCons release, 4.0.0, is now available
>>   on the SCons download page:
>>
>>   https://scons.org/pages/download.html
>>
>>   Here is a summary of the changes since 3.1.2:
>>
>>   NEW FUNCTIONALITY
>>
>> - Added support for scanning multiple entries in an action string if
>>   IMPLICIT_COMMAND_DEPENDENCIES is set to 2 or 'all'. This enables
>> more thorough
>>   action scanning where every item in each command line is scanned to
>> determine
>>   if it is a non-source and non-target path and added to the list of
>> implicit dependencies
>>   for the target.
>> - Added new module SCons.Scanner.Python to allow scanning .py files.
>> - Added support for explicitly passing a name when creating Value()
>> nodes. This may be useful
>>   when the value can't be converted to a string or if having a name
>> is otherwise desirable.
>> - Added a new flag called "linedraw" for the command line argument
>>  "--tree"
>>   that instructs scons to use single line drawing characters to draw
>> the dependency tree.
>> - Add CompilationDatabase() builder in compilation_db tool.
>> Contributed by MongoDB.
>>   Setting COMPILATIONDB_USE_ABSPATH to True|False controls whether
>> the files are absolute or relative
>>   paths.  Address Issue #3693 and #3694 found during development.
>> - Extended `Environment.Dump()` to select a format to serialize
>> construction variables (pretty, json).
>> - New conditional C Scanner (`SCons.Scanner.C.CConditionalScanner()`)
>>   which interprets C/C Preprocessor conditional syntax (#ifdef, #if,
>> #else,
>>   #elif, #define, etc.)
>> - Experimental New Feature: Enable caching MSVC configuration
>>   If SCONS_CACHE_MSVC_CONFIG shell environment variable is set,
>>   SCons will cache the results of past calls to vcvarsall.bat to
>>   a file; integrates with existing memoizing of such vars.
>> - Preliminary Python 3.9 support.
>>
>>   DEPRECATED FUNCTIONALITY
>>
>> - Drop support for Python 2.7. SCons will be Python 3.5+ going
>> forward.
>> - Remove deprecated SourceCode()
>>
>>   CHANGED/ENHANCED EXISTING FUNCTIONALITY
>>
>> - Added check for SONAME in environment to setup symlinks correctly
>> (Github Issue #3246)
>> - Resolve Issue #3248 - Removing '-Wl,-Bsymbolic' from
>> SHLIBVERSIONFLAGS
>>   NOTE: If your build depends on the above you must now add to your
>> SHLIBVERSIONFLAGS
>> - Microso

[Scons-dev] SCons 4.0.0 Released

[Bill Deegan]

  A new SCons release, 4.0.0, is now available
  on the SCons download page:

  https://scons.org/pages/download.html

  Here is a summary of the changes since 3.1.2:

  NEW FUNCTIONALITY

- Added support for scanning multiple entries in an action string if
  IMPLICIT_COMMAND_DEPENDENCIES is set to 2 or 'all'. This enables more
thorough
  action scanning where every item in each command line is scanned to
determine
  if it is a non-source and non-target path and added to the list of
implicit dependencies
  for the target.
- Added new module SCons.Scanner.Python to allow scanning .py files.
- Added support for explicitly passing a name when creating Value()
nodes. This may be useful
  when the value can't be converted to a string or if having a name is
otherwise desirable.
- Added a new flag called "linedraw" for the command line argument
 "--tree"
  that instructs scons to use single line drawing characters to draw
the dependency tree.
- Add CompilationDatabase() builder in compilation_db tool. Contributed
by MongoDB.
  Setting COMPILATIONDB_USE_ABSPATH to True|False controls whether the
files are absolute or relative
  paths.  Address Issue #3693 and #3694 found during development.
- Extended `Environment.Dump()` to select a format to serialize
construction variables (pretty, json).
- New conditional C Scanner (`SCons.Scanner.C.CConditionalScanner()`)
  which interprets C/C Preprocessor conditional syntax (#ifdef, #if,
#else,
  #elif, #define, etc.)
- Experimental New Feature: Enable caching MSVC configuration
  If SCONS_CACHE_MSVC_CONFIG shell environment variable is set,
  SCons will cache the results of past calls to vcvarsall.bat to
  a file; integrates with existing memoizing of such vars.
- Preliminary Python 3.9 support.

  DEPRECATED FUNCTIONALITY

- Drop support for Python 2.7. SCons will be Python 3.5+ going forward.
- Remove deprecated SourceCode()

  CHANGED/ENHANCED EXISTING FUNCTIONALITY

- Added check for SONAME in environment to setup symlinks correctly
(Github Issue #3246)
- Resolve Issue #3248 - Removing '-Wl,-Bsymbolic' from SHLIBVERSIONFLAGS
  NOTE: If your build depends on the above you must now add to your
SHLIBVERSIONFLAGS
- Microsoft Visual Studio - switch to using uuid module to generate
GUIDs rather than hand rolled
  method using md5 directly.
  NOTE: This change affects the following builders' output. If your
build depends on the output of these builders
  you will likely see a rebuild.
  * Package() (with PACKAGETYPE='msi')
  * MSVSSolution()
  * MSVSProject()
- Improve Visual Studio solution/project generation code to add support
  for a per-variant cppflags. Intellisense can be affected by cppflags,
  this is especially important when it comes to /std:c++* which
specifies
  what C++ standard version to target. SCons will append /Zc:__cplusplus
  to the project's cppflags when a /std:c++* flag is found as this is
  required for intellisense to use the C++ standard version from
cppflags.
- Allow user specified location for vswhere.exe specified by VSWHERE.
  NOTE: This must be set at the time the 'msvc' 'msvs' and/or 'mslink'
tool(s) are initialized to have any effect.
- Fixed Github Issue 3628 - Hardcoding pickle protocol to 4 (supports
python 3.4+)
  and skipping Python 3.8's new pickle protocol 5 whose main advantage
is for out-of-band data buffers.
  NOTE: If you used Python 3.8 with SCons 3.0.0 or above, you may get a
a pickle protocol error. Remove your
  .sconsign.dblite. You will end up with a full rebuild.
- MSVC updates: When there are multiple product installations (e.g,
Community and
  Build Tools) of MSVC 2017 or MSVC 2019, an Enterprise, Professional,
  or Community installation will be selected before a Build Tools
installation when
  "14.1" or "14.2" is requested, respectively. (GH Issue #3699).
- MSVC updates: When there are multiple product installations of MSVC
2017 (e.g.,
  Community and Express), 2017 Express is no longer returned when
"14.1" is
  requested.  Only 2017 Express will be returned when "14.1Exp" is
requested.
  (GH Issue #3699).
- MSVC updates: pass on VSCMD_DEBUG and VSCMD_SKIP_SENDTELEMETRY to msvc
  tool setup if set in environment. Add Powershell to default env
  (used to call telemetry script).
- Renamed as.py to asm.py and left redirecting tool.  'as' is a
reserved word and so
  changing the name was required as we wanted to import symbols for use
in compilation_db
  tool.
- Add no_progress (-Q) option as a set-able option. However, setting it
in the
  SConstruct/SConscript will still cause "scons: Reading SConscript
files ..." to be
  printed, since the option is not set when the build scripts first get
read.
- Docbook builder provides a fallback if lxml fails to generate
 

Re: [Scons-dev] Question on adding .C suffix to CXXSuffixes

[Bill Deegan]

Not a bug.
Probably better to send such emails to the user mailing list.

.C can be c++ vs .c which is C..

-Bill

On Wed, Jun 17, 2020 at 3:04 PM Don Baldwin  wrote:

> Hi,
>
>
>
> I noticed the following code in …/scons/SCons/Tool/cxx.py
>
>
>
> CXXSuffixes = ['.cpp', '.cc', '.cxx', '.c++', '.C++', '.mm']
>
> if SCons.Util.case_sensitive_suffixes('.c', '.C'):
>
> CXXSuffixes.append('.C')
>
>
>
> Is this a bug?  Why are we adding ‘.C’ to CXXSuffixes when we haven’t
> added ‘.c’?
>
>
>
> -Don
>
> (new to this group, but been using an older version of SCons for a few
> years now)
> ___
> 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] Important Notice: Changed in 4.0.0 to default links flags for Versioned Shared Libraries.

[Bill Deegan]

Important Notice:
The -Bsymbolic flag will be removed in 4.0.0 from SHLIBVERSIONFLAGS in the
gnulink Tool. Versioned shared libraries will no longer have this flag
applied to the link step by default.

Use of this flag is unsafe in C++ projects because it leads to ODR
violations and can interfere with proper behavior of new/delete.

We believe a build system should not, by default, introduce the potential
for undefined behavior.

Projects which were relying on automatic application of -Bsymbolic in
versioned shared libraries must now explicitly add the -Bsymbolic flag to
SHLIBVERSIONFLAGS or SHLIBFLAGS` in their project setup.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons on Debian

[Bill Deegan]

Thanks for the update!
Good news indeed.

-Bill

On Mon, Feb 3, 2020 at 3:55 AM Russel Winder  wrote:

> Hi,
>
> Debian has just update their version of SCons, and now it runs on
> Python 3 not Python 2. Win.
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] SCons 3.1.2 Released

[Bill Deegan]

Glad that helped!
Big thanks to Mats Wichmann for that one!

On Sat, Dec 21, 2019 at 10:41 AM Eric Fahlgren 
wrote:

> On Mon, Dec 16, 2019 at 7:02 PM Bill Deegan 
> wrote:
>
>> - EXPERIMENTAL NEW FEATURE: Enable caching MSVC configuration
>>   If SCONS_CACHE_MSVC_CONFIG shell environment variable is set,
>>   SCons will cache the results of past calls to vcvarsall.bat to
>>   a file; integrates with existing memoizing of such vars.
>>   On vs2019 saves 5+ seconds per SCons invocation, which really
>>   helps test suite runs.
>>
>
> Thanks a bunch for this one!  Our bare, no-target 'scons' invocation is
> down to about 0.8 seconds now, and we can do a single DLL build in ~2.5 s,
> which makes things very snappy indeed.
> ___
> 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] SCons 3.1.2 Released

[Bill Deegan]

  A new SCons checkpoint release, 3.1.2, is now available
  on the SCons download page:

  https://scons.org/pages/download.html

  Here is a summary of the changes since 3.1.1:

  NOTE: The 4.0.0 Release of SCons will drop Python 2.7 Support

  NEW FUNCTIONALITY
- Added debug option "action_timestamps" which outputs to stdout the
absolute start and end time for each target.

  REMOVED FUNCTIONALITY
- Turn previously deprecated debug options into failures:
  --debug=tree, --debug=dtree, --debug=stree, --debug=nomemoizer.
- Remove deprecated SourceSignatures, TargetSignatures
- Remove deprecated Builder keywords: overrides and scanner
- Remove deprecated env.Copy
- Remove deprecated BuildDir plus SConscript keyword build_dir


  CHANGED/ENHANCED EXISTING FUNCTIONALITY
- Update Command() function to accept target_scanner, source_factory,
and target_factory arguments.
  This makes Command act more like a one-off builder.
- Added support for "-imacros" to ParseFlags
- EXPERIMENTAL NEW FEATURE: Enable caching MSVC configuration
  If SCONS_CACHE_MSVC_CONFIG shell environment variable is set,
  SCons will cache the results of past calls to vcvarsall.bat to
  a file; integrates with existing memoizing of such vars.
  On vs2019 saves 5+ seconds per SCons invocation, which really
  helps test suite runs.

  FIXES
- Fix suncxx tool (Oracle Studio compiler) when using Python 3.
Previously would throw an exception.
  Resolved by properly handling tool version string output as unicode.
- Resolved a race condition in multithreaded Windows builds with Python
2
  in the case where a child process is spawned while a Python action
has a
  file open. Original author: Ryan Beasley.
- Fix CheckFunc detection code for Visual 2019. Some functions
  (e.g. memmove) were incorrectly recognized as not available.
- Fix stacktrace when using SCons with Python 3.5+ and SunOS/Solaris
related tools.
- Latex: Avoid crash with UnicodeDecodeError on Python 3 when a Latex
log file in
  non-UTF-8 encoding (e.g. containing umlauts in Latin-1 encoding when
  the fontenc package is included with \usepackage[T1]{fontenc}) is
read.
- CmdStringHolder fix from issue #3428

  IMPROVEMENTS
- Improved threading performance by ensuring NodeInfo is shared
  across threads. Results in ~13% improvement for parallel builds
  (-j# > 1) with many shared nodes.
- Improve performance of Entry.disambiguate() by making check for
  most common case first, preventing unnecessary IO.
- Improved DAG walk performance by reducing unnecessary work when
  there are no un-visited children.


  PACKAGING

 - N/A

  DOCUMENTATION

-  N/A

  DEVELOPMENT

- N/A


Thanks to the following developers for their contributions to this release.
git shortlog --no-merges -ns 3.1.1..HEAD
59  Mats Wichmann
21  William Deegan
 8  Edoardo Bezzeccheri
 5  Adam Gross
 5  maiphi
 4  Ivan Kravets
 4  Mathew Robinson
 2  Jakub Kulík
 2  Jacek Kuczera
 2  Rob Boehne
 2  Jason Kenny
 2  Tim Gates
 1  Jakub Kulik
 1  Theogen Ratkin
 1  jw0k
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] revisiting CI setup

[Bill Deegan]

I'd say since appveyor windows builds have sped up so much we can decrease
the split per py type from /4 to maybe /2 or maybe /1
I think the max runtime per build is 1hr?

On Mon, Dec 16, 2019 at 2:26 PM Mats Wichmann  wrote:

>
> time passes... so time to ask some questions again.
>
>
> The travis build does two code-coverage runs (2.7 and 3.6), then seven
> regular runs (2.7, 3.5, 3.6, 3.7, 3.8-dev, pypy2 and pypy3.
>
> The appveyor build, despite a recent caching hack that sped it up a lot,
> is still much slower, and thus is asked to do less work, but has a more
> complex scenario: it needs to test itself on three different appveyor
> images, each provisioned with a different Visual Studio version, so what
> it runs is: 2.7 on VS2017 image, 3.5 on VS2015 image, 3.6 on VS2017
> image (this is also a coverage run), 3.7 on VS2019 image.
>
> We're having some test problems due to evolution of Windows images - in
> particular (there are github issues on this), clang tests do not run
> properly, because before it always found the mingw clang, but in the
> VS2019 image that is no longer installed by default, and the setup
> doesn't work with a "native" clang - basically this exposed an untested
> issue, rather than breaking something that was working.
>
> 3.8 is fully released now.  only the Linux CI (travis) is running the
> tests under 3.8, and it's using "3.8-dev" as opposed to an officially
> released version of 3.8. Although it's early days yet, there ought to be
> a 3.9-dev (last I checked, appveyor hadn't enabled that choice, but that
> was a while back)
>
> what sets of these are actually important for checking that a PR does
> not introduce testing regressions?
>
> I'm unconvinced the pypy tests add any value in this context. Maybe we
> could move them to the buildbot setup instead? In particular, pypy3 has
> never gained the performance of pypy2, and doesn't seem to be in active
> development, and the performance is a killer for our use of it.
>
> We should be able to stop testing 2.7 once develoment flips to "4.0",
> since it won't carry the compatibility promise any longer.
>
> Is there any other way to rearrange/improve this, including the
> mentioned buildbot - things which aren't deemed critical to run on every
> PR but which still would be useful to see the progress of could move to
> buildbot
>
> ___
> 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] Bug in MSVC_BATCH handling

[Bill Deegan]

Generally issues like this should go to the users mailing list.
(Mainly so searching users mailing list will find issues run into by users).

Good catch.
Any chance you can put together a PR with a test?
-Bill

On Sun, Dec 15, 2019 at 12:13 PM Eric Fahlgren 
wrote:

> Py 3.7 64, Win 10 64
> SCons 3.1.1 (but same as master in this case)
>
> While cleaning up some old scripts, I uncovered a bug that I've been
> working around for who knows how long and finally isolated it.
>
> Problem: When MSVC_BATCH is enabled globally, files with different target
> name are built individually, but ignoring the specified $TARGET name.
> Here's a little example, note the first argument to the "cl" output.
>
> Input:
> env = Environment(MSVC_BATCH=True)
> bug32 = env.Object(target='file32', source='file.cpp')
>
> Output:
> cl  /FoWIN32\src\\  /c  WIN32\src\file.cpp
>
> If you explicitly suppress batching in the Object, then it works fine.
> Input:
> obj32 = env.Object(target='file32', source='file.cpp', MSVC_BATCH=False)
> Output:
> cl  /FoWIN32\src\file32.obj  /c  WIN32\src\file.cpp
>
> I chased this to the logic in Tool.msvc, the function msvc_output_flag
> where it's checking the state of the MSVC_BATCH variable, and ignores the
> difference in base name that the function just above (msvc_batch_key)
> performs, see lines 168-173.  My hack, which seems to work, is to change
> line 191 in msvc.py from:
>
> 191: if 'MSVC_BATCH' not in env or env.subst('$MSVC_BATCH') in ('0', '
> False', '', None):
>
> to use the already-working logic in the batch key function like this:
>
> 191:if msvc_batch_key(None, env, target, source) is None:
>
> I tried it on single file and multi-file compilations, and from my cursory
> playing around, this keeps the batched files together and separates out
> those with different target base names, but then I didn't try all cases or
> check any other downstream code in the pipeline to see if this would break
> anything there...
>
> ___
> 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] RFC: Proposal for remote caching

[Bill Deegan]

re switching hashes.
Do we have any perf comparisons for MD5 vs SHA-256 in general and in SCons?
While I think adding SHA-256 has value, I'd be hesitant to make it the
default and/or remove MD5.
Also there needs to be a reasonable solution to (de)serializing which hash
is used to sconsign.

On Mon, Dec 9, 2019 at 1:34 PM Mats Wichmann  wrote:

>
> > 2.1.3 Changes Needed To Bazel Remote Cache Server
> >
> > Currently the Bazel remote cache server only supports SHA-256 for
> requests (e.g. GET http://bazel-cache.corp.int/cache/ac/),
> while SCons by default uses MD5. As part of this project, VMware will be
> contributing code to the upstream Bazel remote cache server project to
> support MD5 and SHA-1. We have received confirmation from the project
> maintainer that (1) it is acceptable to do this and (2) no prefix is needed
> for these alternative hashing formats. As a result, the requests SCons
> would make would be of the form 
> http://bazel-cache.corp.int/cache/ac/
> or http://bazel-cache.corp.int/cache/ac/. As mentioned before,
> see the Threat Modeling section at the end of this page for more discussion
> on hash formats.
>
> I'm not sure we should actually further push md5.  While it's not
> intended to be used for security purposes (and yes I read the section on
> that), we've already run into users who are not allowed to use it no
> matter what (there's a pending patch to failover to sha1 to address one
> of those users' concerns)... and there are fast algorithms in the SHA-2
> family as well as ones that didn't quite make the SHA-3 choice (namely,
> Blake) which are quite fast on Python.  It may be time to transition?
>
> ___
> 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] Processed: Re: scons: Python2 removal in sid/bullseye

[Bill Deegan]

SCons can't tell (in general) if the SConstructs/SConscripts run with SCons
aren't py3 compatible except when user runs scons with py3.
That said we'll be dropping py2 support with SCons 4.0.
Timeline for that's a bit in flux.

That said the scripts installed current expect "python" and not "python2"
or "python3"

On Tue, Dec 3, 2019 at 2:01 PM Changwoo Ryu  wrote:

> In general, it would be helpful if the Scons project has a policy of
> deprecating python 2.x, e.g. printing a warning message for py2
> project files. Without such policy, people will just use old project
> files.
>
> And for distributions, it would be also useful to have a policy about
> command names for scons+python2 and scons+python3, like PEP 394.
> Fedora seems to choose /usr/bin/scons-2 and /usr/bin/scons-3.
>
>
> 2019년 12월 4일 (수) 오전 12:47, Bill Deegan 님이 작성:
> >
> > So sounds like the SCons project doesn't need to do anything.
> > It's up to the projects which use SCons?
> >
> > -Bill
> >
> > On Mon, Dec 2, 2019 at 10:09 PM Changwoo Ryu  wrote:
> >>
> >> 2019년 12월 3일 (화) 오후 1:58, Bill Deegan 님이 작성:
> >> >
> >> > What do you need me to do?
> >> >
> >> > -Bill
> >> > SCons Project Co-Manager.
> >>
> >> I just merged the duplicated bugs and marked version. :)
> >>
> >> I understand that Debian scons py3 switching is not easy because of
> >> the py2 dependent build files. In case of Fedora, py3 ready packages
> >> use python3-scons which includes /usr/bin/scons-3 for python3. Anyway
> >> the transition plan is up to the maintainer(s) decision.
> >>
> >> Regards,
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Processed: Re: scons: Python2 removal in sid/bullseye

[Bill Deegan]

So sounds like the SCons project doesn't need to do anything.
It's up to the projects which use SCons?

-Bill

On Mon, Dec 2, 2019 at 10:09 PM Changwoo Ryu  wrote:

> 2019년 12월 3일 (화) 오후 1:58, Bill Deegan 님이 작성:
> >
> > What do you need me to do?
> >
> > -Bill
> > SCons Project Co-Manager.
>
> I just merged the duplicated bugs and marked version. :)
>
> I understand that Debian scons py3 switching is not easy because of
> the py2 dependent build files. In case of Fedora, py3 ready packages
> use python3-scons which includes /usr/bin/scons-3 for python3. Anyway
> the transition plan is up to the maintainer(s) decision.
>
> Regards,
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] [Scons-users] Notice: SCons will drop Python 2.7.* support with SCons version 4.0.0 before end of 2019

[Bill Deegan]

Not sure what to tell you.

It's not that hard to specify env['PYTHON27']='path to python 27'
And then use '$PYTHON27  " in your builders.

Or are you not running your non-python3 code outside your scons process?

Also keep in mind, there's nothing to prevent you from running the last
pre-4.0 scons in perpetuity.

-Bill

On Mon, Sep 30, 2019 at 2:21 PM Fred Wright  wrote:

>
> On Mon, 30 Sep 2019, Bill Deegan wrote:
>
> > To simplify support and to enable us to use some native Python 3.5+
> features we'll be dropping python 2.7.* support with SCons
> > version 4.0.0 which we expect to release before the end of 2019.
>
> Unfortuately I didn't have a chance to vote against this, but an important
> point is being missed here.  Although it's possible in principle for a
> project to build for a different Python version than the one running
> SCons, nothing is offered to assist with that, and many projects don't
> bother to provide the necessary code to allow the distinction.  For such
> projects, the only way to specify a target Python is to run SCons with
> that Python.  For such projects, any dropping of Python versions in SCons
> is then inflicted on those projects.  And if they provide Python modules
> used by other projects, *those* projects are also impacted.  Thus, there
> is a huge domino effect, which is especially significant in Python 2 vs.
> Python 3, due to Python 3's incompatibilities.
>
> > Note that Python 2.7 is End of Life is Jan 1, 2020.
> > https://pythonclock.org/
>
> Anyone who equates "end of life" with "expiration" has obviously never
> worked with hardware. :-)
>
> Fred Wright
> ___
> Scons-users mailing list
> scons-us...@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Notice: SCons will drop Python 2.7.* support with SCons version 4.0.0 before end of 2019

[Bill Deegan]

Greetings,

To simplify support and to enable us to use some native Python 3.5+
features we'll be dropping python 2.7.* support with SCons version 4.0.0
which we expect to release before the end of 2019.

We have no intention of removing any published version from pypi so if
you're stuck on Python 2.7.* you shouldn't see your builds break or have to
migrate to another build system.

Note that Python 2.7 is End of Life is Jan 1, 2020.
https://pythonclock.org/

-Bill
Co-Manager, SCons Project
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Twitter poll on dropping py27 support

[Bill Deegan]

Mats,

We did a deprecation cycle last time we dropped python version support.

Could roll a 3.1.2 with current updates and add deprecation warning to it..

-Bill

On Fri, Sep 6, 2019 at 1:57 PM Mats Wichmann  wrote:

> On 9/5/19 1:23 PM, Bill Deegan wrote:
> > https://twitter.com/SConsProject/status/1169688929903230976?s=20
>
>
> I voted, but I guess it depends on how near "in the near future" is.
>
> do you want to do a deprecation cycle?  the python version supported
> isn't really an "scons feature" so I don't know if it's required.
>
>
> ___
> 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] Twitter poll on dropping py27 support

[Bill Deegan]

Ivan,

If possible vote on Twitter.

On Fri, Sep 6, 2019 at 10:50 AM Ivan Van Laningham 
wrote:

> My vote probably doesn't count for much, but I vote yes, drop py27.
>
> Metta,
> Ivan
>
> On Fri, Sep 6, 2019 at 8:47 AM Bill Deegan 
> wrote:
>
>> Yes. scons-local packages are still published.
>>
>> Dropping py27 allows us to get rid of  a bunch of if PY3/PY27 code. Also
>> we can start using PY3.5+ specific packages/logic.
>> (This will reduce the maintenance/testing load once the old code is
>> purged)
>>
>> -Bill
>>
>> On Fri, Sep 6, 2019 at 10:38 AM anatoly techtonik 
>> wrote:
>>
>>> What are pros and cons of dropping `py27`?
>>>
>>> I did not monitor anything recently. Can SCons still be dropped into
>>> target repository and work from there without any additional
>>> dependencies?
>>>
>>> On Fri, Sep 6, 2019 at 3:51 PM Bill Deegan 
>>> wrote:
>>> >
>>> > Feel free to send to users mailing list
>>> >
>>> > On Fri, Sep 6, 2019 at 5:52 AM anatoly techtonik 
>>> wrote:
>>> >>
>>> >> Any voting options for non-Twitter people?
>>> >>
>>> >>
>>> >> On Thu, Sep 5, 2019 at 10:23 PM Bill Deegan <
>>> b...@baddogconsulting.com> wrote:
>>> >> >
>>> >> > https://twitter.com/SConsProject/status/1169688929903230976?s=20
>>> >> > ___
>>> >> > Scons-dev mailing list
>>> >> > Scons-dev@scons.org
>>> >> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> anatoly t.
>>> >> ___
>>> >> Scons-dev mailing list
>>> >> Scons-dev@scons.org
>>> >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>> >
>>> > ___
>>> > Scons-dev mailing list
>>> > Scons-dev@scons.org
>>> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>>
>>>
>>> --
>>> anatoly t.
>>> ___
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
>
>
> --
> Ivan Van Laningham
> God N Locomotive Works
> http://www.pauahtun.org/
>
> http://www.python.org/workshops/1998-11/proceedings/papers/laningham/laningham.html
> Army Signal Corps:  Cu Chi, Class of '70
> Author:  Teach Yourself Python in 24 Hours
> ___
> 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] Twitter poll on dropping py27 support

[Bill Deegan]

Yes. scons-local packages are still published.

Dropping py27 allows us to get rid of  a bunch of if PY3/PY27 code. Also we
can start using PY3.5+ specific packages/logic.
(This will reduce the maintenance/testing load once the old code is purged)

-Bill

On Fri, Sep 6, 2019 at 10:38 AM anatoly techtonik 
wrote:

> What are pros and cons of dropping `py27`?
>
> I did not monitor anything recently. Can SCons still be dropped into
> target repository and work from there without any additional
> dependencies?
>
> On Fri, Sep 6, 2019 at 3:51 PM Bill Deegan 
> wrote:
> >
> > Feel free to send to users mailing list
> >
> > On Fri, Sep 6, 2019 at 5:52 AM anatoly techtonik 
> wrote:
> >>
> >> Any voting options for non-Twitter people?
> >>
> >>
> >> On Thu, Sep 5, 2019 at 10:23 PM Bill Deegan 
> wrote:
> >> >
> >> > https://twitter.com/SConsProject/status/1169688929903230976?s=20
> >> > ___
> >> > Scons-dev mailing list
> >> > Scons-dev@scons.org
> >> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >>
> >>
> >>
> >> --
> >> anatoly t.
> >> ___
> >> Scons-dev mailing list
> >> Scons-dev@scons.org
> >> https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Twitter poll on dropping py27 support

[Bill Deegan]

Feel free to send to users mailing list

On Fri, Sep 6, 2019 at 5:52 AM anatoly techtonik 
wrote:

> Any voting options for non-Twitter people?
>
>
> On Thu, Sep 5, 2019 at 10:23 PM Bill Deegan 
> wrote:
> >
> > https://twitter.com/SConsProject/status/1169688929903230976?s=20
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> --
> anatoly t.
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Twitter poll on dropping py27 support

[Bill Deegan]

https://twitter.com/SConsProject/status/1169688929903230976?s=20
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] bug prune

[Bill Deegan]

O.k.
I'll try to get this setup this weekend.

On Thu, Sep 5, 2019 at 3:47 AM Russel Winder  wrote:

> On Tue, 2019-09-03 at 11:44 -0700, Bill Deegan wrote:
> > On one hand dropping the number of open bugs will have significant
> > appearance/PR  improvements.
> > (I've seen comments saying 600+ bugs outstanding the project must not be
> > still alive).
>
> I'd say having a lot of open bugs in a project that clearly has regular
> commits (as SCons does) could lead to the the thought that the SCons team
> doesn't care about submitted issues – rather than being a dead project.
>
> Age of bugs is also a dimension. Bugs open for more than a few years
> indicate
> a "no-one actually cares about this" and so are candidates for closing with
> the option of reopening – or better a new bug opening given the difference
> between the software now compared to then.
>
> > But dropping 620 of 680 bugs because they're stale, but possibly still
> > unresolved issues probably isn't the best.
>
> It depends. Some may just not be relevant any more. Given the rate of
> change
> of SCons code base, any bug report unaddressed in say five years should be
> closed.
>
> > Would we tag them stale and close them, allowing them to be identified as
> > possibly not resolved, but with no recent activity?
>
> Or delete them in the hope of getting a new bug report if the problem is
> still
> a real one.
>
> > We used to have weekly (ish) bug triage IRC meetings.
> > Though to be honest some issues never got addressed because the time
> > required to thoroughly investigate them and resolve and the few people
> > reporting them dropped their effective priority.
> >
> > Thoughts?
>
> I was never able to get involved in triaging since the meeting were always
> held as a time when I was in bed a sleep.
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] bug prune

[Bill Deegan]

On one hand dropping the number of open bugs will have significant
appearance/PR  improvements.
(I've seen comments saying 600+ bugs outstanding the project must not be
still alive).

But dropping 620 of 680 bugs because they're stale, but possibly still
unresolved issues probably isn't the best.

Would we tag them stale and close them, allowing them to be identified as
possibly not resolved, but with no recent activity?

We used to have weekly (ish) bug triage IRC meetings.
Though to be honest some issues never got addressed because the time
required to thoroughly investigate them and resolve and the few people
reporting them dropped their effective priority.

Thoughts?

On Mon, Sep 2, 2019 at 7:30 AM Mats Wichmann  wrote:

> On 9/2/19 8:03 AM, Jonathon Reinhart wrote:
> > Note that you can subscribe to a GitHub issue without commenting. This
> > is preferred as it avoids spamming all currently-subscribed users.
> >
> > Also, I think mass/automated bug closing needs to be done very
> > conservatively. Closing an issue doesn't make the bug go away. There are
> > projects that have bots which close issues after 30 days of inactivity,
> > and I find it infuriating.
>
> I'm not a fan of the rapid/aggressive closing either, wasn't suggesting
> that. The idea of a bot is to keep there from being so much manual work
> to get the notifications sent, and the closing done. If the team prefers
> no not keep it after the prune, it can just be turned off.
>
> There are a decent number of bugs that were created over 10 years ago,
> and many in the 3-10 year range, and which, due to the migration from
> tigris, aren't really associated with people who may have reported them,
> or commented on them.
>
> The idea of commenting to keep a bug alive is to defeat the bot's idea
> of what is active (and to confirm "yes, this is still a problem").  I
> don't think subscribing to it does that.
>
>
>
>
> ___
> 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] bug prune

[Bill Deegan]

Dirk,

If you can create a HTML dump, I can put it up on the scons.org webserver
and link to it.
And then maybe we create a repo to check in all the source files with
scripts to regen?

-Bill

On Sat, Aug 31, 2019 at 5:09 AM Dirk Bächle  wrote:

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

[Scons-dev] SCons 3.1.1 Released

[Bill Deegan]

 SCons - a software construction tool

What is SCons?

SCons is an Open Source software construction tool—that is, a
next-generation build tool. Think of SCons as an improved, cross-platform
substitute for the classic Make utility with integrated functionality
similar to autoconf/automake and compiler caches such as ccache. In short,
SCons is an easier, more reliable and faster way to build software.


Change Log

RELEASE 3.1.1 - Mon, 07 Aug 2019 20:09:12 -0500

  From William Deegan:
- Remove obsoleted references to DeciderNeedsNode which could cause
crash when using --debug=explain

  From Jason Kenny
- Add Fix and test for crash in 3.1.0 when using
Decider('MD5-timestamp') and --debug=explain

  From Ben Reed:
- Added -fmerge-all-constants to flags that get included in both
CCFLAGS and LINKFLAGS.

  From Mathew Robinson:
- Fix issue #3415 - Update remaining usages of EnvironmentError to
SConsEnvironmentError
  this patch fixes issues introduced in 3.1.0 where any of the
  following would cause SCons to error and exit:
- CacheDir not write-able
- JSON encoding errors for CacheDir config
- JSON decoding errors for CacheDir config
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] SCons 3.1.0 Released

[Bill Deegan]

A new SCons checkpoint release, 3.1.0, is now available
  on the SCons download page:

  https://scons.org/pages/download.html

SCons is an Open Source software construction tool—that is, a
next-generation build tool. Think of SCons as an improved, cross-platform
substitute for the classic Make utility with integrated functionality
similar to autoconf/automake and compiler caches such as ccache. In short,
SCons is an easier, more reliable and faster way to build software.

  Here is a summary of the changes since 3.0.5:

  NEW FUNCTIONALITY

- Added variable TEMPFILEARGJOIN to specify how to join arguments
written
  to temp files used when command lines exceed MAXLINELENGTH when the
  command uses $TEMPFILE{...}
- Support for MSVC 2019
- Upgraded and improved Visual Studio solution/project generation code
using the MSVSProject builder.
  - Added support for Visual Studio 2017 and 2019.
  - Added support for the following per-variant parameters to the
builder:
- cpppaths: Provides per-variant include paths.
- cppdefines: Provides per-variant preprocessor definitions.


  CHANGED/ENHANCED EXISTING FUNCTIONALITY

  - Fix performance degradation for MD5-timestamp decider.  NOTE: This
changes the Decider() function arguments.
  From:
  def my_decider(dependency, target, prev_ni):
  To:
  def my_decider(dependency, target, prev_ni, repo_node):
  Where repo_node is the repository (or other) node to use to check if
the node is out of date instead of dependency.

- Enhanced --debug=explain output. Now the separate components of the
dependency list are split up
  as follows:

  scons: rebuilding `file3' because:
   the dependency order changed:
   ->Sources
   Old:xxx New:zzz
   Old:yyy New:yyy
   Old:zzz New:xxx
   ->Depends
   ->Implicit
   Old:/usr/bin/python New:/usr/bin/python

- Changed: Pseudo-builders now inherit OverrideEnvironments. For
  example when calling a pseudo-builder from another
  pseudo-builder the override variables passed to the first
  pseudo-builder call had to be explicitly passed on to the
  internal pseudo-builder call. Now the second pseudo-builder call
  will automatically inherit these override values.

  FIXES
- Fix Issue #3350 - SCons Exception EnvironmentError is conflicting
with Python's EnvironmentError.
- Fix spurious rebuilds on second build for cases where builder has > 1
target and the source file
  is generated. This was causing the > 1th target to not have it's
implicit list cleared when the source
  file was actually built, leaving an implicit list similar to follows
for 2nd and higher target
  ['/usr/bin/python', 'xxx', 'yyy', 'zzz']
  This was getting persisted to SConsign and on rebuild it would be
corrected to be similar to this
  ['zzz', 'yyy', 'xxx', '/usr/bin/python']
  Which would trigger a rebuild because the order changed.
  The fix involved added logic to mark all shared targets as peers and
then ensure they're implicit
  list is all cleared together.
- Fix Issue #3349 - SCons Exception EnvironmentError is conflicting
with Python's EnvironmentError.
  Renamed to SConsEnvironmentError
- Fix Issue #3350 - mslink failing when too many objects.  This is
resolved by adding TEMPFILEARGJOIN variable
  which specifies what character to join all the argements output into
the tempfile. The default remains a space
  when mslink, msvc, or mslib tools are loaded they change the
TEMPFILEARGJOIN to be a line separator (\r\n on win32)
- Additional fix to issue #3135 - Also handle 'pure' and 'elemental'
type bound procedures

- Fix handling of Visual Studio Compilers to properly reject any
unknown HOST_PLATFORM or TARGET_PLATFORM
- Enable LaTeX scanner to find more than one include per line

  under which they would be observed), or major code cleanups

git shortlog --no-merges -ns 3.0.5..HEAD
64  William Deegan
56  Mats Wichmann
10  Adam Gross
 4  Mathew Robinson
 4  Peter Diener
 3  Lukas Schrangl
 1  Daniel Holth
 1  bdbaddog
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] SCons is Sourceforge's June 2019 Project of the month!

[Bill Deegan]

Congrats to all involved!

https://sourceforge.net/blog/june-2019-staff-pick-project-month-scons/
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] portability of docbook tests

[Bill Deegan]

change the fixture files form .xsl to .xsl.in and then add a text subst
builder to  work on them?

On Thu, May 30, 2019 at 6:55 AM Mats Wichmann  wrote:

> On 5/29/19 9:17 PM, Bill Deegan wrote:
> > o.k. probably worth moving locations to test infrastructure and makeing
> > a call to check for skips and provide the location for inclusion the
> file?
>
> I don't recall, can fixture files be modified as they're being copied to
> the test directory? Since the path is hardcoded in the .xsl files as
> well as the tests themselves that seems like it would be needed.
>
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] portability of docbook tests

[Bill Deegan]

o.k. probably worth moving locations to test infrastructure and makeing a
call to check for skips and provide the location for inclusion the file?

On Wed, May 29, 2019 at 3:33 PM Mats Wichmann  wrote:

> On 5/29/19 4:26 PM, Bill Deegan wrote:
> > Which tests use those?
> >
> > On Wed, May 29, 2019 at 2:43 PM Mats Wichmann  > <mailto:m...@wichmann.us>> wrote:
> >
> > On 5/29/19 3:34 PM, Bill Deegan wrote:
> > > Which files in SCons are you referring to?
> >
> > the paths were partially in my message - missing the prefix
> > test/Docbook, so to pick one and complete it:
> >
> > test/Docbook/basedir/htmlchunked/image/html.xsl
>
> these are the skips due to tests that check for the files at specific
> paths, checks that were presumably added because tests otherwise failed
> on some platform.
>
>
> test/Docbook/basedir/htmlchunked/htmlchunked.py
> test/Docbook/basedir/htmlchunked/htmlchunked_cmd.py
> test/Docbook/basedir/htmlhelp/htmlhelp.py
> test/Docbook/basedir/htmlhelp/htmlhelp_cmd.py
> test/Docbook/basedir/slideshtml/slideshtml.py
> test/Docbook/basedir/slideshtml/slideshtml_cmd.py
> test/Docbook/basic/slideshtml/slideshtml.py
> test/Docbook/basic/slideshtml/slideshtml_cmd.py
> test/Docbook/rootname/htmlchunked/htmlchunked.py
> test/Docbook/rootname/htmlhelp/htmlhelp.py
> test/Docbook/rootname/slideshtml/slideshtml.py
>
> ___
> 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] portability of docbook tests

[Bill Deegan]

Which tests use those?

On Wed, May 29, 2019 at 2:43 PM Mats Wichmann  wrote:

> On 5/29/19 3:34 PM, Bill Deegan wrote:
> > Which files in SCons are you referring to?
>
> the paths were partially in my message - missing the prefix
> test/Docbook, so to pick one and complete it:
>
> test/Docbook/basedir/htmlchunked/image/html.xsl
> ___
> 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] portability of docbook tests

[Bill Deegan]

Which files in SCons are you referring to?
Possibly stick some logic in the test framework to find the "Home" of the
docbook stylesheets?


On Wed, May 29, 2019 at 1:06 PM Mats Wichmann  wrote:

>
> Just tossing this out here in case anybody has any ideas.  It's not a
> big thing, but has led to a bunch of test skips on my own systems, which
> don't run Ubuntu, ever since I've been running tests, and every now and
> then it irritates me enough to give it a bit of a thought.
>
> A subset of the docbook tests use xsl:import to bring in stylesheets.
> But the paths to them are hardcoded, and only correct for Ubuntu
> (probably inherited from Debian and shared with other relatives like
> Mint), not for other Linux distributions, and certainly not for Windows:
>
> basedir/htmlchunked/image/html.xsl: 
> href="file:///usr/share/xml/docbook/stylesheet/docbook-xsl/html/chunkfast.xsl"/>
>
> basedir/htmlhelp/image/htmlhelp.xsl:
> href="file:///usr/share/xml/docbook/stylesheet/docbook-xsl/htmlhelp/htmlhelp.xsl"/>
>
> basedir/slideshtml/image/slides.xsl:
> href="file:///usr/share/xml/docbook/stylesheet/docbook-xsl/slides/html/plain.xsl"/>
>
> rootname/htmlchunked/image/html.xsl:
> href="file:///usr/share/xml/docbook/stylesheet/docbook-xsl/html/chunkfast.xsl"/>
>
> rootname/htmlhelp/image/htmlhelp.xsl:   
> href="file:///usr/share/xml/docbook/stylesheet/docbook-xsl/htmlhelp/htmlhelp.xsl"/>
>
> rootname/slideshtml/image/slides.xsl:   
> href="file:///usr/share/xml/docbook/stylesheet/docbook-xsl/slides/html/plain.xsl"/>
>
>
>
> any thoughts on how one might make these more "portable" and not just
> tied to one particular filesystem layout?
>
>
> ___
> 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] Looking for help mapping Windows pdb semantics to SCons

[Bill Deegan]

Andrew & Adam,

Unless the discussion is proprietary, perhaps there would be value in
continuing it on list?
That would make it easier for others to follow the development process and
also in the future look back and understand some of the why?

-Bill

On Fri, May 24, 2019 at 3:45 PM Andrew C. Morrow 
wrote:

>
> Hi Adam -
>
> I'm working in this same area (caching and debug info handling) for the
> SCons based MongoDB build system, right now.
>
> Overall, I am trying to move to a model on Windows that is more like using
> -gsplit-dwarf with the GNU tools, where every object file gets a
> (cacheable) .pdb, and then we link with /DEBUG:fastlink, and defer the
> final per library/executable PDB to a post link step by using mspdbcmf.
> This is similar to using dwp to package up the .dwo files.
>
> You can see some of my very much work-in-progress state here:
> https://github.com/acmorrow/mongo/blob/SERVER-33661/site_scons/site_tools/separate_debug.py
>
> Unfortunately, I've encountered one showstopper issue for us:
> https://developercommunity.visualstudio.com/content/problem/573023/absolute-paths-for-associated-pdb-files-are-record.html,
> and I'm waiting to hear back on it.
>
> The next steps in my current approach would be to move the actions that
> produce the finalized .dwp, .dSYM, or .pdb file into separate builders,
> rather than adding them as actions to the .Program and .SharedLibrary
> builders. That would allow the build tasks to finalize the debug
> information to be executed separately, or not at all for developer builds
> where keeping the debug info in separated per-object files is sufficient.
>
> If you are interested, I'd be happy to collaborate (off-list initially?)
> to discuss some of the issues we have encountered and find a way to avoid
> duplication of effort. Improving the debug info handling situation is
> something I'm keenly interested in, as it is a major bottleneck in our
> build performance.
>
> Thanks,
> Andrew
>
>
>
> On Fri, May 24, 2019 at 3:45 PM Tomasz Gajewski  wrote:
>
>>
>> Adam Gross via Scons-dev  writes:
>>
>> > I am investigating better supporting caching with SCons at VMware and
>> > am trying to see if I can teach SCons about pdb files.
>>
>> Is there any problem for your use cases in using /Z7 option for
>> compilation? That tells the compiler to embed debug data in .obj file
>> like on linux. Then during linking pdb's are created. It works at least
>> for shared libraries and executables.
>>
>> Regards
>> Tomasz Gajewski
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Looking for help mapping Windows pdb semantics to SCons

[Bill Deegan]

Mats,

What builders can't you cache?

-Bill

On Fri, May 24, 2019 at 3:56 PM Mats Wichmann  wrote:

> For all you guys, is the current caching - all filesystem based - useful
> enough? I've been chewing on a network based extension, for all those
> disposable builders that don't really have great ways to cache
>
>
> On May 24, 2019 3:45:01 PM MDT, "Andrew C. Morrow" <
> andrew.c.mor...@gmail.com> wrote:
>>
>>
>> Hi Adam -
>>
>> I'm working in this same area (caching and debug info handling) for the
>> SCons based MongoDB build system, right now.
>>
>> Overall, I am trying to move to a model on Windows that is more like
>> using -gsplit-dwarf with the GNU tools, where every object file gets a
>> (cacheable) .pdb, and then we link with /DEBUG:fastlink, and defer the
>> final per library/executable PDB to a post link step by using mspdbcmf.
>> This is similar to using dwp to package up the .dwo files.
>>
>> You can see some of my very much work-in-progress state here:
>> https://github.com/acmorrow/mongo/blob/SERVER-33661/site_scons/site_tools/separate_debug.py
>>
>> Unfortunately, I've encountered one showstopper issue for us:
>> https://developercommunity.visualstudio.com/content/problem/573023/absolute-paths-for-associated-pdb-files-are-record.html,
>> and I'm waiting to hear back on it.
>>
>> The next steps in my current approach would be to move the actions that
>> produce the finalized .dwp, .dSYM, or .pdb file into separate builders,
>> rather than adding them as actions to the .Program and .SharedLibrary
>> builders. That would allow the build tasks to finalize the debug
>> information to be executed separately, or not at all for developer builds
>> where keeping the debug info in separated per-object files is sufficient.
>>
>> If you are interested, I'd be happy to collaborate (off-list initially?)
>> to discuss some of the issues we have encountered and find a way to avoid
>> duplication of effort. Improving the debug info handling situation is
>> something I'm keenly interested in, as it is a major bottleneck in our
>> build performance.
>>
>> Thanks,
>> Andrew
>>
>>
>>
>> On Fri, May 24, 2019 at 3:45 PM Tomasz Gajewski  wrote:
>>
>>>
>>> Adam Gross via Scons-dev  writes:
>>>
>>> > I am investigating better supporting caching with SCons at VMware and
>>> > am trying to see if I can teach SCons about pdb files.
>>>
>>> Is there any problem for your use cases in using /Z7 option for
>>> compilation? That tells the compiler to embed debug data in .obj file
>>> like on linux. Then during linking pdb's are created. It works at least
>>> for shared libraries and executables.
>>>
>>> Regards
>>> Tomasz Gajewski
>>>
>>> ___
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> 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-users] scons: windows architecture mapping tables

[Bill Deegan]

Moving conversation to dev mailing list as that's the appropriate forum.
-Bill

On Tue, May 7, 2019 at 7:36 AM Mats Wichmann  wrote:

>
> By accident I again ended up seeing the architecture tables for
> Windows/Visual Studio.  I had made some changes in the past guessing at
> support for newer things (arm appeared a while ago, and 64-bit arm in, I
> think VS2017).  They are out of sync, but I don't really know what I'm
> doing here, and don't know if that actually breaks anything. I'm just
> here from inspection, not through chasing a known problem. Hoping
> someone else knows this stuff better and has comments.
>
> There are actually three tables (unless there are more I have missed).
>
>
> src/engine/SCons/Tool/MSCommon/arch.py  and
> src/engine/SCons/Platform/win32.py
>
> have identically named facilities, and ArchDefinition class and a
> SupportedArchitectureList and SupportedArchitectureMap
>
> not sure it's a great idea for there to be two copies of the same thing,
> as they can get out of sync - in fact, they are out of sync. Both use
> "x86_64" as the name for that architecture; the former includes "arm",
> the latter does not; neither includes "aarch64" for 64-bit ARM.
>
> src/engine/SCons/Tool/MSCommon/vc.py
>
> has an _ARCH_TO_CANONCIAL dict which defines the canoncial name "amd64"
> instead of "x86_64" - I know this is what Microsoft likes to call it;
> does it matter that the other two use "x86_64", or is that the "scons
> name" for the architecture?   That dict does define both arm and aarch64.
>
> ___
> Scons-users mailing list
> scons-us...@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Trying out discord for chat as a possible IRC replacement

[Bill Deegan]

Please give it a try and let me know what you think.

Here's an invite link.
https://discord.gg/bXVpWAy

Thanks,
Bill
SCons Project Co-Manager
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Extension of the problem with submodulres definition in fortran (#3135)

[Bill Deegan]

Please attach the zip file to the github issue.
And add comments as to what constructs need to be supported which aren't
already described in the other comments and also by SCons

-Bill

On Mon, Apr 22, 2019 at 11:10 AM Javier GONZALEZ PLATAS 
wrote:

> Hello,
> I have found an extension of the problem reported as #3135 (May2018) about
> "Does not handle fortran submodules and type bound procedures correctly".
>
> For this case, someone give a solution to compile this type of files that
> it
> works only in a particular case but not in general (under my opinion).
>
> I'm sending a zip file containing a modified version from previous
> example. The main difference is that now there are two aditional files.
> The current version of SConstruct give again the problem.  In this case,
> the files used are  test_1.f90, test_2.f90, test_22.f90,
> test_submodules.f90.
>
> If you change the version test_22.f90 by test_21.f90 the scons works
> without problem. But in general, test_22.f90 is also a correct file.
>
> Any suggestion?
>
> Javier González Platas
>
>
>
> Departamento de Física
> Avda. Astrofísico Fco. Sánchez s/n
> Apartado 456
> 38200 La Laguna. S/C de Tenerife
>
> T. 922 318 251
> M. 629 080 140
>
> ull.es 
> --
> Aviso de confidencialidad
> 
> ___
> 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] SCons 3.0.5 Released

[Bill Deegan]

A new SCons release, 3.0.5, is now available on the SCons download page:

https://scons.org/pages/download.html

And via pypi:
pip install scons

SCons is a tool for building software (and other files).  SCons is
implemented in Python, and its "configuration files" are actually Python
scripts, allowing you to use the full power of a real scripting language
to solve build problems.  You do not, however, need to know Python to
use SCons effectively.


Here is a summary of the changes since 3.0.4:

CHANGED/ENHANCED EXISTING FUNCTIONALITY

  - Change the default for AppendENVPath to delete_existing=0, so path
order will not be changed, unless explicitly set (Issue #3276)
  - Add lex construction variable LEXUNISTD for turning off unix headers on
windows
  - Update lex tool to use win_flex on windows if available
  - Add the textfile tool to the default tool list

FIXES

  - Fix Issue #3283 - Handle using --config=force in combination with
Decider('MD5-timestamp').
3.0.2 in fix for issue #2980 added that deciders can throw
DeciderNeedsNode exception.
The Configure logic directly calls the decider when using
--config=force but wasn't handling
that exception.  This would yield minimally configure tests using
TryLink() not running and
leaving TypeError Nonetype exception in config.log
  - Fix Issue #3303 - Handle --config=force overwriting the Environment
passed into Configure()'s
Decider and not clearing it when the configure context is completed.
  - Add default paths for yacc tool on windows to include cygwin, mingw,
and chocolatey
  - Fix issue #2799 - Fix mingw tool to respect SHCCCOMSTR, SHLINKCOMSTR
and LDMODULECOMSTR
  - Fix Issue #3329 - Add support for MS SDK V10.0A (which is commonly
installed with VS2017)
  - Fix Issue # - Add support for finding vswhere under 32 bit windows
installs.
  - Update the MSVC tool to include the nologo flag by default in RCFLAGS
  - Fixed bug which threw error when running SCons on windows system with
no MSVC installed.


IMPROVEMENTS
  - Do not store build host+user name if reproducible builds are wanted


git shortlog --no-merges -ns 3.0.4..HEAD
34  William Deegan
33  Mats Wichmann
18  Daniel
 4  Daniel Moody
 3  Bernhard M. Wiedemann
 2  Maciej Kumorek
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Adding SCons support for VCPkg

[Bill Deegan]

Ryan,

Interesting project.
Likely something more generic (with per platform logic) might be optimal.
That said we might not want to throw away the good waiting for the perfect..
I believe other build tools have similar existing functionality, so this
could certainly be an interesting feature to add.

SOURCE:
Am I safe in assuming the source would be a github repo?
Or could it also be a zip file you download?  Would you specify the
version/branch/tag for such?
Would you want newer versions to be retrieved as they are published?

TARGET:
I think you'll have to list at least all the files which other parts of the
build could depend on.
So headers, sources, libraries, data files?

Re bootstrapping:
Can vcpkg be installed via chocolatey?
I'm thinking minimally the default should not be to download and bootstrap,
but an optional flag could indicate to do so.
Thought it could get pretty messy.
Almost too bad vcpkg doesn't include a sconscript.. that'd make it simpler
to bootstrap inside scons.

-Bill



On Sat, Mar 16, 2019 at 2:38 PM Ryan Saunders  wrote:

> Hi SCons developers!
>
>
>
> I am working on a SCons tool integrating the new VCPkg package manager
> from Microsoft (https://github.com/Microsoft/vcpkg). VCPkg makes it
> pretty straightforward to acquire 3rd party libraries and header
> files…”vcpkg install boost” is basically equivalent to “apt-get install
> boost-devel” on Ubuntu. Personally, I’m excited about this, as acquiring
> and configuring development libraries on Windows has been painful,
> historically. VCPkg works on Windows, Linux and MacOS (though I've only
> tried it on Windows so far.)
>
>
>
> (Note: I work for Microsoft, but not on anything related to VCPkg or
> Visual Studio…this is strictly a side project for me.)
>
>
>
> I envision it working something like this:
>
>
>
> env = Environment(tools = [‘default’, ‘vcpkg’])
>
> env.Replace( VCPKGROOT = ‘#/some/path/vcpkg’ )  # Override default root
> directory of #/vcpkg
>
> …
>
> env.VCPkg( ‘boost-smart-ptr’ )
>
> env.VCPkg( ‘FreeImagePlus’ )
>
>
>
> …possibly with some as-yet-unspecified integration with the Configure
> context, so that packages can be auto-installed if not found.
>
>
>
> Basically, my goal is to be able to “git clone” a project onto a machine
> with just Git, VS and Python installed, and then to build successfully
> (including acquiring all necessary libraries) simply by running “scons”.
>
>
>
> Some questions I have:
>
>- Is this something that would be acceptable/desirable as part of
>SCons core, or should I be thinking of this as a tool that lives in its own
>repo?
>- It occurs to me that, while this does work on Linux/MacOS, these
>systems have their own native package management solutions for acquiring
>development libs. So, perhaps this would be better as a sort of
>“meta-package-manager” tool that uses VCPkg on Windows, and something
>native-ish on other systems. On the other hand, those tools usually require
>root access to use, so maybe that’s not a good idea. Thoughts?
>- In my current prototype, if VCPkg is not found, then I’m downloading
>it and building it via its “bootstrap” script. However, I’m not sure where
>the best place to do this is…I could do it in my tool’s generate()
>function, which seems logical, but this appears to be called immediately
>upon loading the tool, before the SConscript has an opportunity to override
>VCPKGROOT. What do you recommend?
>- I’m having difficulty deciding what “source” and “target” should be
>for my Builder.
>   - Based on scouring the ‘net, it seems that I want to use a Value()
>   as my “source”…probably just the string name of the package to be
>   installed. Does that sound right?
>   - For “target”, would it be better to exhaustively enumerate all
>   the outputs of “vcpkg install ” and list these as “targets”, or 
> should
>   I find some single file that gets produced by installing a package 
> (e.g.,
>   the package manifest), and use this as a “sentinel” for the whole 
> package?
>   The latter is clearly simpler, but could this result in an incomplete
>   incremental rebuild after upgrading to a newer version of the package?
>
>
>
> Any advice you can provide would be appreciated!
>
> Ryan
>
>
>
>
> ___
> 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] Try 3.0.5a3

[Bill Deegan]

All,

If you have a few, please try 3.0.5a3

virtualenv venv
. venv/bin/activate
pip install --index-url https://test.pypi.org/simple/ scons==3.0.5a3
scons --version

Let us know if you find any issues.
May try to roll up 3.0.5 and release this weekend.

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

Re: [Scons-dev] [Scons-users] Alpha release 3.0.5a2

[Bill Deegan]

It's an alpha so whatever was in master as of this morning.
Just really for the Mesa team to verify their issue is addressed.

BTW - Mesa folks, re-enable md5-timestamp to test.

On Tue, Mar 5, 2019 at 3:04 PM Eric Fahlgren  wrote:

> And, yes, works for me.  I don't think I'm testing any new functionality,
> but no regressions for our full build.
>
> On Tue, Mar 5, 2019 at 11:55 AM Eric Fahlgren 
> wrote:
>
>> Bill, I think that should be:
>>
>> > pip install --index-url https://test.pypi.org/simple/ scons==3.0.5a2
>>
>> On Tue, Mar 5, 2019 at 8:13 AM Bill Deegan 
>> wrote:
>>
>>> Please give this alpha release a try if you can.
>>>
>>> https://github.com/SCons/scons/releases/tag/3.0.5a2
>>>
>>>
>>> You can also try via:
>>>
>>> . venv/bin/activate
>>> pip install --index-url https://test.pypi.org/simple/ 
>>> scons==3.0.0.alpha.20170821
>>> scons --version
>>>
>>> Please let us know if you run into any issues
>>>
>>> -Bill
>>>
>>> SCons, Co-Manager
>>>
>>>
>>> ___
>>> Scons-dev mailing list
>>> Scons-dev@scons.org
>>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>>
>> ___
> Scons-users mailing list
> scons-us...@scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Alpha release 3.0.5a2

[Bill Deegan]

Please give this alpha release a try if you can.

https://github.com/SCons/scons/releases/tag/3.0.5a2


You can also try via:

. venv/bin/activate
pip install --index-url https://test.pypi.org/simple/
scons==3.0.0.alpha.20170821
scons --version

Please let us know if you run into any issues

-Bill

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

Re: [Scons-dev] Subst() replacement?

[Bill Deegan]

There's a pull request on scons repo with the current state of code.
There's a wiki page on the approach as well.
The approach should remove all the recursion, add caching, and pre-tokenize
(so strings aren't tokenized every time they're evaluated).

In the meantime if you want to shortcut some of your recursion. Walk you're
envs and env.Subst() them where it make sense.

I see chains of strings like this

x='$y', y="$z', z='$a' z="$b" b=".obj"

There's likely lots of those which could reduce your recursion.

It's unfortunate that currently SCons has no way of representing makes
":="  and all variables are equivalent to "=" where they're evaluated every
time their referenced..

What do you  expect ${${}} to do?


On Mon, Feb 18, 2019 at 3:14 PM Jason Kenny  wrote:

> Do you have a link for me to look at?
>
> Else I was going to start by making a expression parser to allow the
> breaking up of the $ ${} $() $$ and ${${}} ( this last one is a feature
> improvement) style expression and then make tweaked versions of the
> existing classes in subst module to try to avoid recursion when it can.
>
> Jason
> --
> *From:* Scons-dev  on behalf of Bill Deegan <
> b...@baddogconsulting.com>
> *Sent:* Monday, February 18, 2019 5:05 PM
> *To:* SCons developer list
> *Subject:* Re: [Scons-dev] Subst() replacement?
>
> Jason,
>
> The code I have is still a work in progress.
> Putting it in parts first doesn't make sense to me as when it's ready I'll
> be dropping it into SCons itself, though likely as a switchable alternative
> initially.
>
> I'll be back to working on it in about a month I expect. Maybe sooner.
>
> -Bill
>
> On Mon, Feb 18, 2019 at 11:18 AM Jason Kenny  wrote:
>
> Hi Bill,
>
> I know in the past we have talked about various things to do to fix up
> Scons. One of the items was the subst engine we have. Currently for me the
> issue with Parts is that I use the Subst engine to pass data around between
> different components in a automated way. This works well minus two issues:
>
> 1) it can take time. However I have various tweaks in the object I pass to
> the subst call to help cache a number of cases.
> 2) stack depth. This is the major issue for me at the moment.
>
> The issue with with 2) is seen with -j based builds which can lead to seg
> faults. Depending on the build, it is common to have some depth of 10-20+
> components. This can lead to a stack of depth per thread of 250 to 300+.
> When doing a -j based build this blows the stack in a bad way.
>
> one can easily get stack with this pattern:
>
> ...
> File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 543, in substitute
> return self.expand(args, lvars)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 495, in expand
> return list(map(func, s))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 494, in func
> return conv(substitute(l, lvars))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 526, in substitute
> result = _dollar_exps.sub(sub_match, args)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 525, in sub_match
> return self.conv(self.expand(match.group(1), lvars))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 491, in expand
> return self.substitute(s, lv)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 543, in substitute
> return self.expand(args, lvars)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 509, in expand
> return self.substitute(s, lvars)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 543, in substitute
> return self.expand(args, lvars)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 495, in expand
> return list(map(func, s))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 494, in func
> return conv(substitute(l, lvars))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 543, in substitute
> return self.expand(args, lvars)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 495, in expand
> return list(map(func, s))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 494, in func
> return conv(substitute(l, lvars))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst

Re: [Scons-dev] Subst() replacement?

[Bill Deegan]

Jason,

The code I have is still a work in progress.
Putting it in parts first doesn't make sense to me as when it's ready I'll
be dropping it into SCons itself, though likely as a switchable alternative
initially.

I'll be back to working on it in about a month I expect. Maybe sooner.

-Bill

On Mon, Feb 18, 2019 at 11:18 AM Jason Kenny  wrote:

> Hi Bill,
>
> I know in the past we have talked about various things to do to fix up
> Scons. One of the items was the subst engine we have. Currently for me the
> issue with Parts is that I use the Subst engine to pass data around between
> different components in a automated way. This works well minus two issues:
>
> 1) it can take time. However I have various tweaks in the object I pass to
> the subst call to help cache a number of cases.
> 2) stack depth. This is the major issue for me at the moment.
>
> The issue with with 2) is seen with -j based builds which can lead to seg
> faults. Depending on the build, it is common to have some depth of 10-20+
> components. This can lead to a stack of depth per thread of 250 to 300+.
> When doing a -j based build this blows the stack in a bad way.
>
> one can easily get stack with this pattern:
>
> ...
> File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 543, in substitute
> return self.expand(args, lvars)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 495, in expand
> return list(map(func, s))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 494, in func
> return conv(substitute(l, lvars))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 526, in substitute
> result = _dollar_exps.sub(sub_match, args)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 525, in sub_match
> return self.conv(self.expand(match.group(1), lvars))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 491, in expand
> return self.substitute(s, lv)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 543, in substitute
> return self.expand(args, lvars)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 509, in expand
> return self.substitute(s, lvars)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 543, in substitute
> return self.expand(args, lvars)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 495, in expand
> return list(map(func, s))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 494, in func
> return conv(substitute(l, lvars))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 543, in substitute
> return self.expand(args, lvars)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 495, in expand
> return list(map(func, s))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 494, in func
> return conv(substitute(l, lvars))
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 526, in substitute
> result = _dollar_exps.sub(sub_match, args)
>   File "/build-env/lib/python3.6/site-packages/scons/SCons/Subst.py", line
> 525, in sub_match
> ...
>
> I had mentioned in the past I want to not use the subst call as much, but
> change this with something else is non trivial at the moment. I do recall
> you had done some work on this. I am looking at trying to fix the subst
> logic in Scons . What I propose to do it to override the subst module in
> SCons with Parts. The goal would to be to show a better version we could
> the move in to Scons with minimum effort as well as allow me to move
> forward with out having to block on a new SCons drop.
>
> I believe you had done work on this already. I was hoping I could try to
> start with that with hope this can be used to reduce the recursion issues
> in SCons. This seemed to be better than start from scratch.
>
> Oh course if you have a better idea I am
>
> Jason
>
>
> ___
> 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] windows and non-thread Pythons

[Bill Deegan]

Check the docs on 2.7, but I'm pretty sure all pythons 3.5+ build with
threads.

On Fri, Feb 8, 2019 at 11:01 AM Mats Wichmann  wrote:

>
> One of the windows scons source files uses subprocess to run vswhere,
> and it calls suprocess.communicate.  This is new code and seems to be
> working fine as far as I know.
>
> Another source file calls a vcvars* batch script, and does not use
> subprocess.communicate, with the following comment:
>
> # Use the .stdout and .stderr attributes directly because the
> # .communicate() method uses the threading module on Windows
> # and won't work under Pythons not built with threading.
>
> Is that a Thing any longer? Windows Pythons not built with threading? Or
> is this a special-case that can be eliminated?
> ___
> 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] Vote for SCons for Sourceforge Project of the Month

[Bill Deegan]

I know it's clunky, but please vote if you have a few minutes.


https://sourceforge.net/p/potm/discussion/vote/thread/29aa49b937/?limit=25=1#56fe
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Appveyor testing platforms

[Bill Deegan]

By default scons does not use  os.environ's PATH.
The test framework does for some tools though ideally SCons would cover
reasonable default paths for windows tools.

If the install path in appveyor is not a reasonable default, then it may
make sense to have the test find the path and provide it to the test logic.
Otherwise it's more "sconsian" to add the reasonable default into the tool
logic.

Can you add information about the tools provided to the PR summary?
Just trying to make it easier for folks to trace back any logic changes to
infrastructure (and code) to the PR's and their expected effects.



On Wed, Jan 30, 2019 at 9:40 AM Daniel Moody  wrote:

> I'm fairly certain that even though most of these tools are installed,
> they are not part of the default PATH, so you may need to add them near the
> top of the appveyor file where we add some other things like mingw. Also
> depends on how the tools are being found in scons code, is the os.environ
> used at all or is it just assumed default paths? You may have to ask
> appveyor support where the WIX tools are installed. Do you know a common
> place they would be? The new appveyor.yml should call set to print the env
> to the log, so you could check the path.
>
> On Wed, Jan 30, 2019 at 11:26 AM Mats Wichmann  wrote:
>
>> On 1/30/19 10:12 AM, Daniel Moody wrote:
>> > Windows Server 2012:
>> > Visual Studio 2008 Express
>> > Visual Studio 2010 Pro/Express
>> > Visual Studio 2012 Pro/Express
>> > Visual Studio 2013 Community
>> > Visual Studio 2015 Community
>> >
>> > Windows Server 2016:
>> > Visual Studio 2015 Community
>> > Visual Studio 2017 Community
>> >
>> > Also software versions for the different Windows can be found:
>> > https://www.appveyor.com/docs/windows-images-software/
>>
>> Okay, this was interesting... I've tried adding wix toolset
>> (https://github.com/SCons/scons/pull/3204), and that causes the build to
>> break.  But according to that chart, it's already included, under Misc
>> SDKs:
>>
>> WiX Toolset 3.11.0.1701
>>
>> So why are we not finding the preinstalled one?
>>
>> Some of the entries show the paths to look at, but wix isn't one of those.
>>
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Appveyor testing platforms

[Bill Deegan]

which versions of VS are on each?

On Tue, Jan 29, 2019 at 7:59 PM Daniel Moody  wrote:

> Appveyor CI used with Github only alots 1 job to run at time. It can take
> 6 - 10 hours to run all the tests on the all the different Windows
> environments. I would like to reduce the redundancy here a bit to decrease
> the time it takes for the Windows CI to complete. Appveyor supports two
> different versions of windows, Windows Server 2012 (like Windows
> 8) and Windows Server 2016 (like Windows 10). The two versions of windows
> have different versions of software installed such as Visual Studio, MinGW,
> etc.
>
> *Currently we are running the tests on these platforms:*
>
> Windows Server 2012
> with python 2.7
> with python 3.6
>
> Windows Server 2016
> with python 2.7
> with python 3.5
> with python 3.6
> with python 3.7
>
> *I propose running the tests on these platform configurations:*
>
> Windows Server 2012
> with python 3.5
> with python 3.6
>
> Windows Server 2016
> with python 2.7
> with python 3.7
>
> This should bring the test down to 4-6 hours. Please let me know if you
> have any thoughts on the matter.
>
>
> ___
> 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] proposed change to _SConscript

[Bill Deegan]

Do you have a simple sample script (Without parts) to demonstrate glob not
working as you describe?
Seems like if that wasn't working you might've brought it to our attention?
;)

Also simple (non parts) script to demonstrate how you were trying to do
this with sconscript and repository?

On Mon, Jan 28, 2019 at 2:00 PM Jason Kenny  wrote:

> No,
>
>
>
> I was trying to see if I could achieve this via Repository(), however I
> discovered it failed because Glob() does not seem to work correctly with
> the Repostory() and VariantDir() logic when I recurse search file Files (
> As I do with Pattern() api in Parts… it goes in to a death loop of variant
> directory recursion on itself ☹ ). So instead I am looking having Parts
> detect that a “vcs” object was used and if the checkout directory and the
> .part file directory are different then pass the checkout directory via
> src_dir to the SConscript() call.
>
>
>
> I should note that the _SConscript code still needs a fix to handle more
> than one Repository(). It looks like that a loop has to be added. However
> this seems like a non-trival change.
>
>
>
> Jason
>
>
>
> *From:* Scons-dev  *On Behalf Of *Bill Deegan
> *Sent:* Monday, January 28, 2019 1:03 PM
> *To:* SCons developer list 
> *Subject:* Re: [Scons-dev] proposed change to _SConscript
>
>
>
> are you using Repository to achieve this?
>
>
>
> On Mon, Jan 28, 2019 at 11:01 AM Jason Kenny  wrote:
>
> Hi,
>
>
>
> I would like to make a proposal to for a small change to _SConscript
> function.
>
>
>
> The change is related to code around line 260. ie this section of code:
>
>
>
> try:
>
> fs.chdir(ldir, change_os_dir=sconscript_chdir)
>
> except OSError:
>
> # There was no local directory, so we should be
>
> # able to chdir to the Repository directory.
>
> # Note that we do this directly, not through
>
> # fs.chdir(), because we still need to
>
> # interpret the stuff within the SConscript file
>
> # relative to where we are logically.
>
> fs.chdir(ldir, change_os_dir=0)
>
>
> os.chdir(actual.dir.get_abspath())
>
>
>
>
>
> I would like to change the os.chdir(actual.dir.get_abspath()) to
> os.chdir(ldir.srcnode().abspath)
>
>
>
> I believe this code is more correct and solve an issue I would like to
> correct when calling scons on "out of  source" builds.
>
>
>
> What this changes as documented, should be nothing. What it changes/fixes
> is use of the src_dir keyword in the SConscript() call ( which was
> documented a long time ago).
>
>
>
> What this fixes for me is the ability define a build file that is not in a
> source tree, as if it was in the source tree. In the case Parts I can
> define a Parts that would checkout or used some code checked out via
> another means as if the build file was part of the source tree. The value
> of this is:
>
>
>
> 1) may not have the ability to add new builds files to an existing project
>
> 2) may want to show how a new build system ( as Scons) would add value to
> an existing setup, without having to get build files checked in.
>
> 3) want to build an external project as if the build file was part of the
> project.
>
> 4) other logic related to the above...
>
>
>
> This is basically like an CMake external project for me in Parts as I can
> tell Parts to checkout some code and build it via having a Part file that
> can build it directly or via having it call the native build system via
> Command() or some custom builder.
>
>
>
> This line change would allow for build file to pretend that it exists in
> the source location. It would also allow me to define three basic concepts
> in Parts:
>
>
>
> 1) build/Variant directory ( where we do the build actions)
>
> 2) build file/part_dir directory ( ie the directory in which the build
> file exists)
>
> 3) Source/src_dir directory ( ie where the source exists)
>
>
>
> most of this time the src_dir==part_dir except of out of source cases.
>
>
>
> I wanted to ask about this to make sure there is nothing I might be
> missing that would cause concerns
>
>
>
> If this is fine I would like to make a patch for this for Scons ( vs me
> monkey patching it in Parts)
>
>
>
> Jason
>
>
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https

Re: [Scons-dev] proposed change to _SConscript

[Bill Deegan]

are you using Repository to achieve this?

On Mon, Jan 28, 2019 at 11:01 AM Jason Kenny  wrote:

> Hi,
>
> I would like to make a proposal to for a small change to _SConscript
> function.
>
> The change is related to code around line 260. ie this section of code:
>
> try:
> fs.chdir(ldir, change_os_dir=sconscript_chdir)
> except OSError:
> # There was no local directory, so we should be
> # able to chdir to the Repository directory.
> # Note that we do this directly, not through
> # fs.chdir(), because we still need to
> # interpret the stuff within the SConscript file
> # relative to where we are logically.
> fs.chdir(ldir, change_os_dir=0)
>
> os.chdir(actual.dir.get_abspath())
>
>
> I would like to change the os.chdir(actual.dir.get_abspath()) to
> os.chdir(ldir.srcnode().abspath)
>
> I believe this code is more correct and solve an issue I would like to
> correct when calling scons on "out of  source" builds.
>
> What this changes as documented, should be nothing. What it changes/fixes
> is use of the src_dir keyword in the SConscript() call ( which was
> documented a long time ago).
>
> What this fixes for me is the ability define a build file that is not in a
> source tree, as if it was in the source tree. In the case Parts I can
> define a Parts that would checkout or used some code checked out via
> another means as if the build file was part of the source tree. The value
> of this is:
>
> 1) may not have the ability to add new builds files to an existing project
> 2) may want to show how a new build system ( as Scons) would add value to
> an existing setup, without having to get build files checked in.
> 3) want to build an external project as if the build file was part of the
> project.
> 4) other logic related to the above...
>
> This is basically like an CMake external project for me in Parts as I can
> tell Parts to checkout some code and build it via having a Part file that
> can build it directly or via having it call the native build system via
> Command() or some custom builder.
>
> This line change would allow for build file to pretend that it exists in
> the source location. It would also allow me to define three basic concepts
> in Parts:
>
> 1) build/Variant directory ( where we do the build actions)
> 2) build file/part_dir directory ( ie the directory in which the build
> file exists)
> 3) Source/src_dir directory ( ie where the source exists)
>
> most of this time the src_dir==part_dir except of out of source cases.
>
> I wanted to ask about this to make sure there is nothing I might be
> missing that would cause concerns
>
> If this is fine I would like to make a patch for this for Scons ( vs me
> monkey patching it in Parts)
>
> Jason
>
> ___
> 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] Please try SCons 3.0.4.1 test package

[Bill Deegan]

Planning in releasing tomorrow.
This should fix the issue with 3.0.3 not finding VS/VC 2017

pip install --index-url https://test.pypi.org/simple/ scons==3.0.4.1
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Fwd: SourceForge Project of the Week January 7th, 2019

[Bill Deegan]

Maybe this is helpful:
SF Download stats:
https://sourceforge.net/projects/scons/files/stats/timeline?dates=2018-10-16%20to%202019-01-15=monthly

Pypi stats:
https://pypistats.org/packages/scons

On Mon, Jan 14, 2019 at 10:56 PM anatoly techtonik 
wrote:

> Without absolute digits it is hard to tell if it is not the result of
> exodus of other projects to GitLab etc. =)
>
> On Mon, Jan 14, 2019 at 5:54 PM Mats Wichmann  wrote:
> >
> > On 1/13/19 9:24 PM, William Deegan wrote:
> > > FYI!
> > >
> > > -- Forwarded message -
> > > From: Joan Uy Ang 
> > > Date: Wed, Jan 2, 2019 at 6:08 PM
> > > Subject: SourceForge Project of the Week January 7th, 2019
> > > To:
> > >
> > >
> > > Hi,
> > >
> > > If you’re receiving this email it is because you are listed as an
> admin on
> > > our next Projects of the Week Issue for January 7th, 2019 on the
> > > SourceForge Blog.
> >
> > Which is pretty cool considering scons isn't "on" sourceforge except for
> > the downloadable bundles  :)
> >
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> --
> anatoly t.
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] MSVC Version usage survey Please fill in if you use SCons with Visual Studio

[Bill Deegan]

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

[Scons-dev] SCons Version 3.0.3 Released

[Bill Deegan]

  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

[Bill Deegan]

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

[Bill Deegan]

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] Pulled 3.0.2 from pypi.

[Bill Deegan]

I've pulled the release from pypi.
The .bat files for scons got dropped and breaking some windows users CI.

I'll fix and re-upload when ready.

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

[Scons-dev] SCons 3.0.2 Release

[Bill Deegan]

  A new SCons release, 3.0.2, 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)

  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
   226  William Deegan
79  Daniel Moody
72  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

[Scons-dev] Twitter poll on SCons + Python usage.

[Bill Deegan]

https://twitter.com/SConsProject/status/1077783900644986880

Please add your vote.

-Bill
SCons Project Co-Manager
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] compiler lookups, particularly windows

[Bill Deegan]

The reason it was split is because there's a maximum runtime per job on
appveyor and without splitting into 4 our regression tests on windows
exceed the limit and were getting killed.

Currently not a way to tie the tools used to the builders run by each build.
That could be useful for test runtime, and when users are trying to squeeze
the last bit of performance out of scons..

Though there may be more generally useful features/bugs to spend time on.

-Bill

On Tue, Oct 30, 2018 at 3:53 PM Mats Wichmann  wrote:

> On 10/30/18 2:34 PM, Mats Wichmann wrote:
>
>
> I'm looking at the appveyor page
>
> https://ci.appveyor.com/project/SCons/scons/history
>
> this is a pretty typical display for a build:
>
>  Failed 5 hours ago in 4 hr 44 min
>
> the build is divided into four chunks, but I'm not seeing the purpose of
> that since they apparently still run sequentially, since it's a "free"
> product, we get only one execution stream.
>
> slow builds don't critically hurt this project since there isn't
> honestly that much change activity. still...
>
>
>
>
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] compiler lookups, particularly windows

[Bill Deegan]

What would you propose?

I've spent some time adding:
DefaultEnvironment(tools=[])
and Environment(tools=[] or just list of tools needed by test)
In order to speed up windows tests.

These are generally pretty effective, though getting a minimal set of tools
per test can be time consuming.

-Bill

On Tue, Oct 30, 2018 at 8:08 AM Mats Wichmann  wrote:

>
> Yesterday I tested a small change which improves finding an alternate
> build suite on windows (visual studio being considered primary, build
> tools being "other").  In running the tests, I unintentionally left a
> debug statement in the file and in the log saw this:
>
> XXX FOUND VC: C:\Program Files (x86)\Microsoft Visual
> Studio\2017\BuildTools\VC
>
> a total of 1519 times.
>
> some of this process is kind of expensive... once the lookup that
> generated that message has worked, one of the "vcvars" scripts is run to
> find the actual needed executable and any other details - there's
> already a comment in the code this is an expensive operation ("not
> cheap"), and there's some effort to speed it up.
>
> Is it worth trying to figure out any way to do better at this?  It makes
> test runs on Windows slow, and in particular it means the Windows CI
> build, which is four runs back to back for different Python versions
> take a really long time - to the point where often when you go see if
> your build passed, Appveyor is waiting to even start a build because
> some other build hasn't finished yet.
> ___
> 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] testing with python 3.6 3.7

[Bill Deegan]

I believe the dictionary order maintenance started in 3.5.
We've observed no issues due to this.

-Bill

On Tue, Oct 30, 2018 at 7:03 AM Mats Wichmann  wrote:

> On 10/30/18 7:49 AM, Jason Kenny wrote:
> > Hi,
> > I was wondering if SCons had noticed any testing issues with python 3.6
> or newer. I noticed as I was porting Parts to python3 I was having some
> testing issues related to testing the output of some values that had been
> controlled by values in dict object. I discovered that with python 3.6 and
> made official in 3.7 the insert order is preserved. This caused some false
> positive failures for me as values. I was just curious if this was seen
> with the scons move to python3 as well.
> > Jason
>
> the CI infrastructure (travis and appveyor) builds everything against
> 3.5, 3.6 and 3.7, so those are seen.  There have been several cleanups
> as a result, but mostly those problems have been noise - 3.6 and 3.7
> issuing deprecation warnings by default now, and if those end up in the
> "expected" stderr stream of a test, then it causes problems for that
> test.  There's also a lot of noise from unclosed file descriptors when
> launching other processes via subprocess.  I don't recall seeing any
> test affected by dictionary order... some of the code was already using
> OrderedDict, and I did send a PR through to remove the internal custom
> OrderedDict in favor of the standard library one.
>
> Others may recall something additional...
>
> ___
> 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] unhashable type: 'Literal'' trying to evaluate

[Bill Deegan]

Have you tried the code on master?
There have been some py3 related issues similar to this resolved.
-Bill

On Thu, Oct 25, 2018 at 8:52 AM Jason Kenny  wrote:

> Hi,
>
> I working on getting Parts to work on py3. I think I have most of it
> working at this point, however I had an error that concerned me:
>
> scons: *** [_build/build_debug_posix-x86_64/hello/hello] TypeError
> `unhashable type: 'Literal'' trying to evaluate `${_concat(RPATHPREFIX,
> RPATH, RPATHSUFFIX, __env__)}'
>
> This happens as I tweak the RPATH value with some code like this:
>
> rlst.append(self.env.Literal('{0}$$ORIGIN/{1}{0}'.format(quote, self
> .env.Dir('$INSTALL_BIN').rel_path(
> self.env.Dir('$INSTALL_LIB')
>
> should result in a value such as:
> ["'$$ORIGIN/../lib'"]
>
> This works if I subst() directly at this point. However I am getting a
> stack ( below as it is long) like this which suggests some new behavior?
> This code should be fine and should not have broken. There is no funny
> stuff here in parts.. it a very basic value being set.
>
> Do we know of an issues with Literal() in python 3?
>
> meantime I going to start debugging this "fun" code
>
> - Jason
>
> The stack...
>
> scons: internal stack trace:
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Job.py",
> line 199, in start
> task.prepare()
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Script/Main.py",
> line 175, in prepare
> return SCons.Taskmaster.OutOfDateTask.prepare(self)
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Taskmaster.py",
> line 179, in prepare
> self.exception_raise()
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Taskmaster.py",
> line 554, in _exception_raise
> exec("raise exc_value.with_traceback(exc_traceback)")
>   File "", line 1, in 
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Taskmaster.py",
> line 973, in next_task
> task.make_ready()
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Script/Main.py",
> line 309, in make_ready
> SCons.Taskmaster.OutOfDateTask.make_ready(self)
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Taskmaster.py",
> line 409, in make_ready_current
> t.disambiguate().make_ready()
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Node/FS.py",
> line 3055, in make_ready
> self.get_binfo()
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Node/__init__.py",
> line 1136, in get_binfo
> binfo.bactsig = SCons.Util.MD5signature(executor.get_contents())
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Executor.py",
> line 467, in get_contents
> for action in action_list])
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Executor.py",
> line 467, in 
> for action in action_list])
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Action.py",
> line 535, in get_contents
> result = self.get_presig(target, source, env)
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Action.py",
> line 1112, in get_presig
> return c.get_presig(self, target, source, env)
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Action.py",
> line 1049, in get_presig
> return self._generate(target, source, env, 1,
> executor).get_presig(target, source, env)
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Action.py",
> line 1271, in get_presig
> return b"".join([bytes(x.get_contents(target, source, env)) for x in
> self.list])
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Action.py",
> line 1271, in 
> return b"".join([bytes(x.get_contents(target, source, env)) for x in
> self.list])
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Action.py",
> line 535, in get_contents
> result = self.get_presig(target, source, env)
>   File
> "/home/jkenny/.local/share/virtualenvs/parts-aMB9Fa3Q/lib/python3.6/site-packages/scons-3.0.1/SCons/Action.py",
> line 964, in get_presig
> return env.subst_target_source(cmd, SUBST_SIG, target, source)
>   File
> 

[Scons-dev] Create textmate grammer file so we can have syntax highlighting for sconstruct/sconscript from docs?

[Bill Deegan]

Dirk,

Can we extract all the commands from the docs with the existing doc scripts?
and/or would it be fairly easy to do so?

If so we could auto generate a grammer file for editors syntax highlighting
and completion..

-Bill
___
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?

[Bill Deegan]

Assuming we could resolve the issue of locating the XSLT files installed
from native packages, how different would the namespaces be?

break everything?
Or just renamed?

On Mon, Oct 8, 2018 at 2:42 PM Dirk Bächle  wrote:

> 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] Subprocess.popen() on win32?

[Bill Deegan]

On Sun, Oct 7, 2018 at 2:25 PM Jason Kenny  wrote:

>
>
> I can see what I can do here. I have to make a new Drop of Parts first (
> having a regression in my code I have to fix )
>
>
>
> I don’t believe there should be any limitation. The only issue I believe I
> had was with moving to python 27 as there was a change from 26 in quote
> handling. However we are on 2.7 or better so this should not be an issue.
> Oh there was one other thing. I have to ignore the “escape” function that
> is passed in the SPAWN callback. It breaks with 2.7 on Window and Linux. I
> also removed the Scons override for the open call as it was messing up
> writing to the console device ( Plus I needed to override it to allow
> symbolic and hard links to work on win32)
>

If we're using subprocess.popen() then is escaping needed on linux?

>
>
> Which lead to a question for me on do we have an official way in SCons to
> get the stdout and stderr text from an Action that was called. I don’t
> recall having this before and as such I used the SPAWN to help me add
> logging and colorized text in Parts.
>

As far as I know there's currently no supported way to capture stderr or
stdout from an action. (you can redirect in your command to a file).

Do we lose redirects with swapping in the Popen() ?

-Bill


>
>
> Jason
>
>
>
>
>
> *From:* Scons-dev  *On Behalf Of *Bill Deegan
> *Sent:* Friday, October 5, 2018 12:44 PM
> *To:* SCons developer list 
> *Subject:* Re: [Scons-dev] Subprocess.popen() on win32?
>
>
>
> Jason,
>
>
>
> Any limitations with doing this over the current code?
>
> Could you craft a pull request for this?
>
>
>
> -Bill
>
>
>
> On Fri, Oct 5, 2018 at 10:37 AM Jason Kenny  wrote:
>
> Been using popen with parts via overriding SPAWN var since the start.
>
> +1 on having this be the default
>
> Jason
>
> Get Outlook for Android
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36=02%7C01%7C%7C29e2d6879f7b4620408f08d62aea2038%7C84df9e7fe9f640afb435%7C1%7C0%7C636743582376565412=KcMABMJE2kXb3%2B3UXjnBrUxI%2FR3jFP0D2bI9Nz%2Fzxok%3D=0>
>
>
> --
>
> *From:* Scons-dev  on behalf of Bill Deegan <
> b...@baddogconsulting.com>
> *Sent:* Friday, October 5, 2018 10:32:50 AM
> *To:* SCons developer list
> *Subject:* Re: [Scons-dev] Subprocess.popen() on win32?
>
>
>
> Come now.
>
> Win32.py's spawn implementation was updated in 2012.. ;)
>
>
>
> If we universally switch to subprocess.Popen(), then we can safely chdir
> for non python function actions.
>
> But passing in the cwd argument.
>
>
>
> That seems likely to be useful..
>
>
>
> -Bill
>
>
>
>
>
> On Fri, Oct 5, 2018 at 10:28 AM Russel Winder 
> wrote:
>
> I shall be flippant in the hope of being humorous, yet with an element of
> possible truth:
>
> Perhaps no-one has bothered to update that bit of code in the last decade
> and
> a half?
>
>
> Did you mean subprocess.Popen? Worth noting that the API for subprocess
> changes from call* in earlier versions to run in later. Somewhat annoying
> for
> compatibility across many Python versions.
>
>
> On Fri, 2018-10-05 at 10:17 -0700, Bill Deegan wrote:
> > Greetings,
> >
> > Any reason we're not using subprocess.popen() on win32?
> > We're still using os.spawnve() which is known to have some threading
> issues.
> > https://bugs.python.org/issue6476
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.python.org%2Fissue6476=02%7C01%7C%7C29e2d6879f7b4620408f08d62aea2038%7C84df9e7fe9f640afb435%7C1%7C0%7C636743582376565412=AENwPEuuQxwDeu%2B7E%2F3%2FPXc%2FEWhsxRyw2271hIBHahY%3D=0>
> >
> > -Bill
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist2.pair.net%2Fmailman%2Flistinfo%2Fscons-dev=02%7C01%7C%7C29e2d6879f7b4620408f08d62aea2038%7C84df9e7fe9f640afb435%7C1%7C0%7C636743582376565412=z%2FSuf5LUUJ3pbmybb105S8AvcZkJzK%2FSZkkLsTegesY%3D=0>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.russel.org.uk=02%7C01%7C%7C29e2d6879f7b4620408f08d62aea2038%7C84df9e7fe9f640afb435%7C1%7C0%7C636743582376565412=Hn8BEc6Et%2BR1W6985Rm8otA0qO

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

[Bill Deegan]

Are the docbook xslt stylesheets we're currently including reasonably
available from distro's repos?


On Sun, Oct 7, 2018 at 2:08 PM Dirk Bächle  wrote:

> 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 <http://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
>
___
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?

[Bill Deegan]

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 
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?
>
> W dniu 18.09.2017 o 21:45, Bill Deegan pisze:
> > More data:
> > Here's the failure output when running against package:
> >
> > warning: failed to load external entity
> >
> "/home/bdbaddog/devel/scons/as_scons/build/test-src-tar-gz/lib/scons/SCons/Tool/docbook/utils/xmldepend.xsl"
> > cannot parse
> >
> /home/bdbaddog/devel/scons/as_scons/build/test-src-tar-gz/lib/scons/SCons/Tool/docbook/utils/xmldepend.xsl
> > TypeError: __str__ returned non-string (type NoneType):
> >   File
> >
> "/home/bdbaddog/devel/scons/as_scons/build/test-src-tar-gz/lib/scons/SCons/Script/Main.py",
> > line 1361:
> > _exec_main(parser, values)
> >   File
> >
> "/home/bdbaddog/devel/scons/as_scons/build/test-src-tar-gz/lib/scons/SCons/Script/Main.py",
> > line 1324:
> > _main(parser)
> >   File
> >
> "/home/bdbaddog/devel/scons/as_scons/build/test-src-tar-gz/lib/scons/SCons/Script/Main.py",
> > line 1103:
> > nodes = _build_targets(fs, options, targets, target_top)
> >   File
> >
> "/home/bdbaddog/devel/scons/as_scons/build/test-src-tar-gz/lib/scons/SCons/Script/Main.py",
> > line 1298:
> > jobs.run(postfunc = jobs_postfunc)
> >   File
> >
> "/home/bdbaddog/devel/scons/as_scons/build/test-src-tar-gz/lib/scons/SCons/Job.py",
> > line 111:
> > self.job.start()
> >   File
> >
> "/home/bdbaddog/devel/scons/as_scons/build/test-src-tar-gz/lib/scons/SCons/Job.py",
> > line 214:
> > task.failed()
> >   File
> >
> "/home/bdbaddog/devel/scons/as_scons/build/test-src-tar-gz/lib/scons/SCons/Script/Main.py",
> > line 274:
> > sys.stderr.write(errfmt % (nodename, buildError))
> >
> >
> > On Mon, Sep 18, 2017 at 3:36 PM, Bill Deegan  > <mailto:b...@baddogconsulting.com>> wrote:
> >
> > Dirk,
> >
> > Looks like it's not currently and when I run "python runtest.py -p
> > src-tar-gz -a" to run against the generated packages there are many
> > docbook related failures.
> >
> > Thoughts?
> >
> > _Bill
> >
> >
> >
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
>
>
> --
> Pawel Tomulik
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Subprocess.popen() on win32?

[Bill Deegan]

Jason,

Any limitations with doing this over the current code?
Could you craft a pull request for this?

-Bill

On Fri, Oct 5, 2018 at 10:37 AM Jason Kenny  wrote:

> Been using popen with parts via overriding SPAWN var since the start.
>
> +1 on having this be the default
>
> Jason
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> --
> *From:* Scons-dev  on behalf of Bill Deegan <
> b...@baddogconsulting.com>
> *Sent:* Friday, October 5, 2018 10:32:50 AM
> *To:* SCons developer list
> *Subject:* Re: [Scons-dev] Subprocess.popen() on win32?
>
> Come now.
> Win32.py's spawn implementation was updated in 2012.. ;)
>
> If we universally switch to subprocess.Popen(), then we can safely chdir
> for non python function actions.
> But passing in the cwd argument.
>
> That seems likely to be useful..
>
> -Bill
>
>
> On Fri, Oct 5, 2018 at 10:28 AM Russel Winder 
> wrote:
>
>> I shall be flippant in the hope of being humorous, yet with an element of
>> possible truth:
>>
>> Perhaps no-one has bothered to update that bit of code in the last decade
>> and
>> a half?
>>
>>
>> Did you mean subprocess.Popen? Worth noting that the API for subprocess
>> changes from call* in earlier versions to run in later. Somewhat annoying
>> for
>> compatibility across many Python versions.
>>
>>
>> On Fri, 2018-10-05 at 10:17 -0700, Bill Deegan wrote:
>> > Greetings,
>> >
>> > Any reason we're not using subprocess.popen() on win32?
>> > We're still using os.spawnve() which is known to have some threading
>> issues.
>> > https://bugs.python.org/issue6476
>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.python.org%2Fissue6476=02%7C01%7C%7C2ddb85c900724ee6a19d08d62ae89ce0%7C84df9e7fe9f640afb435%7C1%7C0%7C636743575876087205=6DYlqZyLYzW9cUS2lCdTze3k41YTSNRLrtQA%2Fje1X8Y%3D=0>
>> >
>> > -Bill
>> > ___
>> > Scons-dev mailing list
>> > Scons-dev@scons.org
>> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist2.pair.net%2Fmailman%2Flistinfo%2Fscons-dev=02%7C01%7C%7C2ddb85c900724ee6a19d08d62ae89ce0%7C84df9e7fe9f640afb435%7C1%7C0%7C636743575876087205=2A0pZIv2zZMH6rw19nOwDAetJgMmGhs85WvEWwcx1Sc%3D=0>
>> --
>> Russel.
>> ===
>> Dr Russel Winder  t: +44 20 7585 2200
>> 41 Buckmaster Roadm: +44 7770 465 077
>> London SW11 1EN, UK   w: www.russel.org.uk
>> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.russel.org.uk=02%7C01%7C%7C2ddb85c900724ee6a19d08d62ae89ce0%7C84df9e7fe9f640afb435%7C1%7C0%7C636743575876087205=CQ8ILzxRnVD6Ai6jfJpKs62gFlHwbI7d25lNoZIsYrA%3D=0>
>>
>> ___
>> Scons-dev mailing list
>> Scons-dev@scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist2.pair.net%2Fmailman%2Flistinfo%2Fscons-dev=02%7C01%7C%7C2ddb85c900724ee6a19d08d62ae89ce0%7C84df9e7fe9f640afb435%7C1%7C0%7C636743575876087205=2A0pZIv2zZMH6rw19nOwDAetJgMmGhs85WvEWwcx1Sc%3D=0>
>>
> ___
> 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] Subprocess.popen() on win32?

[Bill Deegan]

Come now.
Win32.py's spawn implementation was updated in 2012.. ;)

If we universally switch to subprocess.Popen(), then we can safely chdir
for non python function actions.
But passing in the cwd argument.

That seems likely to be useful..

-Bill


On Fri, Oct 5, 2018 at 10:28 AM Russel Winder  wrote:

> I shall be flippant in the hope of being humorous, yet with an element of
> possible truth:
>
> Perhaps no-one has bothered to update that bit of code in the last decade
> and
> a half?
>
>
> Did you mean subprocess.Popen? Worth noting that the API for subprocess
> changes from call* in earlier versions to run in later. Somewhat annoying
> for
> compatibility across many Python versions.
>
>
> On Fri, 2018-10-05 at 10:17 -0700, Bill Deegan wrote:
> > Greetings,
> >
> > Any reason we're not using subprocess.popen() on win32?
> > We're still using os.spawnve() which is known to have some threading
> issues.
> > https://bugs.python.org/issue6476
> >
> > -Bill
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Subprocess.popen() on win32?

[Bill Deegan]

Greetings,

Any reason we're not using subprocess.popen() on win32?
We're still using os.spawnve() which is known to have some threading issues.
https://bugs.python.org/issue6476

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

Re: [Scons-dev] env.subst and variable substitution including whitespace in parameters

[Bill Deegan]

Did you try having pipes in your action command string?
I'm thinking it should work..

I wrote the wiki page you mentioned and it's a WIP.

BTW. This is really a scons-users mailing list item and not a scons-dev.


On Mon, Sep 17, 2018 at 10:37 AM RW via Scons-dev 
wrote:

> Hi,
> I'm wondering if this should be filed as a github issue
>
> Recently I ran into a problem, I needed to write a method to pipe some
> input into and out of gcc via the preprocessor
> this meant using subprocess instead of calling an scons Action since I
> wanted to do piping, but to do that I needed to expand outwards the gcc /
> cpppath etc into a string.
> one approach to this might be
>
> ```
> cmdstr = '${CPP} -E ${CFLAGS} ${CCFLAGS} ${_CCCOMCOM} -'
> cmd = env.subst(cmdstr)
> ```
>
> However if any of the include directories include spaces then this doesn't
> work
> we end up with:
> ``
> arm-none-eabi-gcc -E -I. -ID:\Some Folder with whitespace\src -Ibuild -
> ```
> instead of:
> ``
> arm-none-eabi-gcc -E -I. "-ID:\Some Folder with whitespace\src" -Ibuild -
> ```
>
> It turns out the Action / CommandAction class has a way of dealing with
> this.
> the use of env.subst_list and the escape method burried in the
> SCons/Subst.py code
> Typically the function that puts quotes around strings contaning
> whitespace is quote_spaces within SCons/Subst.py
> If I follow the code back, this is called by CmdStringHolder which is only
> referenced within the ListSubber class
> which appears to be used by env.subst_list but not env.subst
>
> The end result after a bit of copying / pasting is the below
> I'm fairly sure this isn't using what's supposed to be public API's
>
> ```
> def generate(env):
> env.AddMethod(PreProcessStream, 'PreProcessStream')
>
>
> def PreProcessStream(env, stdin_str):
> escape = env.get('ESCAPE', lambda x: x)
> escape_list = SCons.Subst.escape_list
>
> cmdstr = '${CPP} -E ${CFLAGS} ${CCFLAGS} ${_CCCOMCOM} -'
> cmd_list = env.subst_list(cmdstr, SCons.Subst.SUBST_CMD)
>
> cmd_list = escape_list(cmd_list[0], escape)
> cmd = ' '.join(cmd_list)
>
> p = subprocess.Popen(cmd, stdout=subprocess.PIPE,
> stdin=subprocess.PIPE, stderr=subprocess.PIPE)
> out, err = p.communicate(input=stdin_str.encode())
> return out, err
> ```
>
> After a bit googling for "env.subst_list" it looks like a few others have
> also used this method
> I also came across this
>
>   * https://github.com/SCons/scons/wiki/ProposalForImprovedSubstEngine
>
> So what I'm proposing here is that perhaps we need some public api way of
> handling this problem without diving into the scons internals
>
> Many Thanks
> Richard
> ___
> 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] Projects Using SCons

[Bill Deegan]

Greetings,

Our list of projects using SCons is very out of date.
If you run or use a project which is built with SCons, please reply with
info about your project?
I'll add them to a list on SCons.org website.

Thanks,
Bill
SCons Project Co-manager
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] packaging tests: tar; and an xz question

[Bill Deegan]

Arg.
Yes this is an existing problem.
Generally it may mean that the tool finding logic needs to be improved
inside SCons.
Though in this case it may mean that for some where_is()'s it may make
sense to have a list of default excluded paths..



On Thu, Sep 6, 2018 at 2:21 PM Mats Wichmann  wrote:

> On 09/06/2018 10:52 AM, Bill Deegan wrote:
> > bz2= test.where_is('bzip2')
>
> so that works, but doesn't work.  ;)
>
>
> where_is('bzip2') locates bzip2 from my cygwin install apparently, but
> when the Windows tar is launched, *it* doesn't find a bzip2.
>
> I think we may have some other instances of that "problem" - finding
> something (in cygwin) during the discovery step, but not having it be
> available at runtime.
>
> ideas?  do I have that wrong?
>
>
> ___
> 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] packaging tests: tar; and an xz question

[Bill Deegan]

bz2= test.where_is('bzip2')
...

On Thu, Sep 6, 2018 at 12:40 PM Mats Wichmann  wrote:

> On 09/06/2018 09:25 AM, Bill Deegan wrote:
> > So it sounds like if there's native windows tar, then there's no need to
> > check for bzip2 executable for windows to be able to handle .tar.bz2
> files?
>
> no, if there's native windows tar it tries to use bzip2 which doesn't
> exist, and the test fails. that's why it never failed before... it never
> found tar before.
>
> so rather, I think in this case we do have to check for bzip2 (we don't
> now). it's less likely to be missing on Linux, but a quick experiment
> shows if I manually get rid of bzip2, tar fails the same way:
>
> # tar -tjf glibc-2.9.tar.bz2
> tar (child): bzip2: Cannot exec: No such file or directory
> tar (child): Error is not recoverable: exiting now
> tar: Child returned status 2
> tar: Error is not recoverable: exiting now
>
> > If that's the case then the test should be updated to figure out which
> tar
> > and if bzip2 is indeed needed to run skip otherwise.
>
> would a check for bzip2 look like this?
>
> bz2 = test.Environment().WhereIs('bzip2')
>
> looks like "figure out which tar" is not needed, just figure out if
> bzip2 is there.
>
> >
> > Regarding xz, pull requests welcome.. ;)
> >
> > -Bill
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev