Re: [Scons-dev] Test failures after recent PRs

[William Blevins]

The D-related ones appear to be from an update in ld or some other tool. I
will look into fixing this later.

V/R,
William

On Mon, Nov 28, 2016 at 8:30 PM, William Blevins 
wrote:

> Bill,
>
> I have some tests failing on Debian Stretch after the last few days of
> tests:
>
> test/D/DMD.py
> test/D/DMD2.py
> test/D/DMD2_Alt.py
> test/D/HSTeoh/sconstest-libCompileOptions_dmd.py
> test/D/HelloWorld/CompileAndLinkOneStep/sconstest-dmd.py
> test/D/HelloWorld/CompileThenLinkTwoSteps/sconstest-dmd.py
> test/D/Issues/2939_Ariovistus/sconstest-correctLinkOptions_dmd.py
> test/D/Issues/2940_Ariovistus/sconstest-correctLinkOptions_dmd.py
> test/D/Issues/2994/D_changed_DFLAGS_not_rebuilding.py
> test/D/MixedDAndC/sconstest-dmd.py
> test/D/MixedDAndC/sconstest-gdc.py
> test/TEX/recursive_scanner_dependencies_import.py
>
> I think the D-related tests could be related to a bug outside SCons, but
> the TEX one may be related legit.
>
> V/R,
> William
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Test failures after recent PRs

[William Blevins]

Bill,

I have some tests failing on Debian Stretch after the last few days of
tests:

test/D/DMD.py
test/D/DMD2.py
test/D/DMD2_Alt.py
test/D/HSTeoh/sconstest-libCompileOptions_dmd.py
test/D/HelloWorld/CompileAndLinkOneStep/sconstest-dmd.py
test/D/HelloWorld/CompileThenLinkTwoSteps/sconstest-dmd.py
test/D/Issues/2939_Ariovistus/sconstest-correctLinkOptions_dmd.py
test/D/Issues/2940_Ariovistus/sconstest-correctLinkOptions_dmd.py
test/D/Issues/2994/D_changed_DFLAGS_not_rebuilding.py
test/D/MixedDAndC/sconstest-dmd.py
test/D/MixedDAndC/sconstest-gdc.py
test/TEX/recursive_scanner_dependencies_import.py

I think the D-related tests could be related to a bug outside SCons, but
the TEX one may be related legit.

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

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

[Dirk Bächle]

Andrew,

On 28.11.2016 23:29, Andrew Featherstone wrote:

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


[...]


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



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


Dirk

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

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

[Andrew Featherstone]

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

Hi,

here are my 2c... ;)

On 28.11.2016 10:36, Russel Winder wrote:

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

Andrew,

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



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

[...]

So this raises a number of issues.

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


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


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


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



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


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



4. Is it just for tools?


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



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


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



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


Creating a pull request.


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


ditto ;)


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


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


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

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


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


Best regards,

Dirk

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


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


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

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

[Saša Janiška]

Dirk Bächle  writes:

> It will be more like the place where Tools get ready to be migrated
> "into" the core, once they have proper tests and documentation. A
> replacement for all the Wiki snippets and, where the current
> maintainers want this, all the single ToolsIndex repos...

Great! :clap:


Sincerely,
Gour

-- 
When your intelligence has passed out of the dense forest
of delusion, you shall become indifferent to all that has
been heard and all that is to be heard.

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

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

[Dirk Bächle]

Hi,

here are my 2c... ;)

On 28.11.2016 10:36, Russel Winder wrote:

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

Andrew,

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



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

[...]

So this raises a number of issues.

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


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


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


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



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


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



4. Is it just for tools?


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


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


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


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


Creating a pull request.


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


ditto ;)


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


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


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

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


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


Best regards,

Dirk

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

Re: [Scons-dev] Hg vs Git

[Jonathon Reinhart]

On Mon, Nov 28, 2016 at 4:42 AM, Russel Winder  wrote:
> On Sun, 2016-11-27 at 14:11 -0500, Jonathon Reinhart wrote:
>> > The point here is that someone can mutate a branch locally and then
>>
>> force it to the mainline.
>>
>> No, that is specifically what protected branches prevent. If "master"
>> is
>> protected, then no one, not even an admin, can re-write history and
>> force
>> push to it.
>
> So if BitBucket supports this, the admins for the mainline SCons and
> SCons-Contrib repositories should mark all the branches as protected?

Not necessarily "all" of the branches, but definitely the ones that
are final/deliverable (e.g. "master" in git parlance). I also
recommend protecting long-lived feature branches, e.g. the Python 3
effort, where multiple people may be working on it for quite a while.

>> Personally, I find the rewriting extremely powerful for my local
>> development - I can re-arrange, split, and join commits in my feature
>> branch before it is merged into master. Very few people are
>> interested in
>> rewriting history of a published tree.
>
> I have never been a user of history rewriting as I tend to publish all
> my repositories all the time. Maybe my workfow and approach is wrong,
> and that I should keep all work private and so rebasable and squashable
> in both Hg and Git until the point of publishing for the pull request?

IMO, it's all about a published branch policy for the project. For example:
- master - Stable at all times; protected; periodically tagged for
major releases
- devel - Bleeding edge; mostly stable; protected; periodically merged
into master at stable points
- (everything else) - In-progress feature/issue branch; **not
protected** and may be rebased/rewritten at any time

This allows you to say "hey guys, check out my WIP branch", but with a
disclaimer that it may be rewritten, giving you the power to go back
and change things based on code review.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Bitbucket Ticket - Please vote

[Bill Deegan]

Greetings,

Bitbucket has "updated" their software to break the generation of
instructions to resolve conflicts on pull requests.

If you have a spare moment, please go vote for this ticket.

https://bitbucket.org/site/master/issues/13454/bring-back-merge-instructions-for-prs-with

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

Re: [Scons-dev] Hg vs Git

[rupert THURNER]

On Nov 28, 2016 10:42, "Russel Winder"  wrote:
>
> On Sun, 2016-11-27 at 14:11 -0500, Jonathon Reinhart wrote:
> > Personally, I find the rewriting extremely powerful for my local
> > development - I can re-arrange, split, and join commits in my feature
> > branch before it is merged into master. Very few people are
> > interested in
> > rewriting history of a published tree.
>
> I have never been a user of history rewriting as I tend to publish all
> my repositories all the time. Maybe my workfow and approach is wrong,
> and that I should keep all work private and so rebasable and squashable
> in both Hg and Git until the point of publishing for the pull request?

Personally I like somebody else looking at my commit, giving feedback and I
then improve it. There are many ways to achieve this. You could just share
via email like done in Linux. Change a commit for a new pull request. Do a
git Gerrit like workflow and push to a mutable branch. Mercurial goes a
step further and marks commits as "draft". A little bit long but might be
worth a read:
http://www.gerg.ca/evolve/sharing.html,
http://gregoryszorc.com/blog/2014/06/23/please-stop-using-mq/

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

Re: [Scons-dev] The Contrib Repository. Footnote.

[Russel Winder]

Sorry I forgot the footnote.

(*) CLion is JetBrains' C, C++, and any other CMake based project IDE.
It is really rather good. Sadly the pressure to add SCons is failing,
ditto Ninja rather than Make as the CMake backend – if they did support
Ninja then they could support Meson as well as CMake very easily.
However, they have already stated that they are staying with CMake but
may eventually provide an API for third-party tooling. 

https://youtrack.jetbrains.com/issue/CPP-1102

https://youtrack.jetbrains.com/issue/CPP-1110

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Hg vs Git

[Russel Winder]

On Sun, 2016-11-27 at 14:11 -0500, Jonathon Reinhart wrote:
> > The point here is that someone can mutate a branch locally and then
> 
> force it to the mainline.
> 
> No, that is specifically what protected branches prevent. If "master"
> is
> protected, then no one, not even an admin, can re-write history and
> force
> push to it.

So if BitBucket supports this, the admins for the mainline SCons and
SCons-Contrib repositories should mark all the branches as protected?

> Personally, I find the rewriting extremely powerful for my local
> development - I can re-arrange, split, and join commits in my feature
> branch before it is merged into master. Very few people are
> interested in
> rewriting history of a published tree.

I have never been a user of history rewriting as I tend to publish all
my repositories all the time. Maybe my workfow and approach is wrong,
and that I should keep all work private and so rebasable and squashable
in both Hg and Git until the point of publishing for the pull request?

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

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

[Russel Winder]

On Sun, 2016-11-27 at 12:42 -0800, Bill Deegan wrote:
> Andrew,
> 
> If it's interesting to you, go ahead and work on it!
> There's an index of community supported builders in the wiki. Feel
> free to
> add your work there (https://bitbucket.org/scons/scons/wiki/ToolsInde
> x).
> Or if you like add it to here: https://bitbucket.org/scons/scons-cont
> rib
> 

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

Currently having the individual repository per tool, it is easy to
clone the repositories to ~/.scons/site_scons/site_tools or
/site_scons/site_tools and things just work.  hg/git/bzr as
management tools have many positive aspects, and a few negative ones,
over any using pip.

The Contrib repository appears to have to be installed, presumably
using setuptools or pip. This is not yet a package on PyPI, so it
cannot be pip-ed in via download, you have to have the hg clone. And
then there is the issue that anyone using a platform with package
management should never use pip into the package managed area – always
use pip --user.

Also it seems that each individual tool in Contrib has to have a
separate installation record, which will be a management nightmare
without automation.

So this raises a number of issues.

1. What is the purpose, aim, and goal of the Contrib repository?
2. Is it intended as the place where things will be migrated out of the
SCons core distribution?
3. Should it deploy into the running SCons installation or to a
site_scons/site_tools?
4. Is it just for tools?
5. Should SCons support not-tool add-ins better?
6. What is the process for adding things to Contrib?
7. What is the mechanism for removing things from Contrib?
8. Is it feasible to move the C, C++, Fortran, D stuff out of the core
without a total rewrite of the core?
9. Is anyone thinking about how to do C++ builds with SCons in the
presence of package managers such as Conan.

In a sense I feel a bit of a fraud contributing here just now. Apart
from LaTeX builds, and a few small pet projects, I am hardly using
SCons just now. CLion (*) required CMake as the build tool, so most of
the C and C++ projects I workl on use CMake, and the other C and C++
projects I am associated with use Autotools :-( or are moving to Meson.
D, Rust, Go, all have their own build systems, and the  Kotlin, Groovy,
Ceylon, Scala, Clojure, Java, i.e. JVM-based languages either use
Gradle (or Maven) or have their own build frameworks (sbt, lein,…)

Having said this, having shoved hard at the Python 3 compatibility for
SCons and the tools as repositories with a central index, I feel a
responsibility to see these through to some form of conclusion, even
though I am using SCons less and less.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev