[Scons-users] SCons popularity

Mon Jun 15 14:53:10 EDT 2015

Arrg stupid buttons.  Was trying to edit this .. and sent it instead.

Try again.

William,

I think the idea is chunks. From talking to Dirk I think the idea is to make SCons and Parts separate. Where Parts had more of an enterprise focus adding stuff that the “mainstream” user may not want or need. Not exactly sure what that means, but the idea seems sound. Given how it has been so far it seems that it will be easier to break Parts up in to modules that SCons can import and use vs trying to change the SCons code to integrate code directly. By using modules,  SCons core can use code from Parts more easily, and kept modular. Also code that is viewed as useful for SCons core can be moved over, for example I have stuff in Parts, such as what I have added to toolchains, which I believe Gary has a different idea about. It seem like there will be items, infra that should be easy to move into SCons and some items, like how I deal with configurations that might be viewed as a more advance feature best kept in Parts. The main thought from me is that Part does try some idea that might not be good. If it does something the is good it can be moved to SCons, if not leave it in Parts.

Just to iterate quickly, I think the first items are to start to break up stuff in Parts as needed, add pip support to SCons and Parts to help make it easier to for any possible mixing and to make it easy for others to extend SCons using Best known method in python.

That is the current thinking as I understand it. Dirk might have some other thoughts to add.

Does answer your question?

Jason

From: Scons-users [mailto:scons-users-bounces at scons.org] On Behalf Of Kenny, Jason L
Sent: Monday, June 15, 2015 1:36 PM
To: SCons users mailing list
Subject: Re: [Scons-users] SCons popularity

William,

I think the idea is chunks. From talking to Dirk I think the idea is to make SCons and Parts separate. Where Parts had more of an enterprise focus adding stuff that the “mainstream” user may not want or need. Not exactly sure what that means, but the idea seems sound. Given how it has been so far it seems that it will be easier to break Parts up in to modules that SCons can import and use vs trying to change the SCons code to finally integrate it in. This was stuff that is agreed to be useful in SCons core from Parts can be moved over easily, and kept modular. Given that I have stuff in Parts, such as what I have added to toolchains, which I believe Gary has a different idea about. It seem like there will be items, infra that should be easy to move into SCons and some items like how I deal with configurations that might be viewed as a more advance feature best kept in Parts. The main thought from me is that Part does try some idea that might not be good. If it does something the is good it can be moved to SCons, if not leave it in Parts. Just to iterate quickly, I think the first items are to start to break up stuff in Parts, add pip support to SCons and Parts to help make it easier to for any possible mixing and to make it easy for others to extend SCons using Best known method in python.

That is the current thinking as I understand it. Dirk might have some other thoughts to add.

Does answer you question?

Jason

From: Scons-users [mailto:scons-users-bounces at scons.org] On Behalf Of William Blevins
Sent: Monday, June 15, 2015 12:14 PM
To: SCons users mailing list
Subject: Re: [Scons-users] SCons popularity

Jason,

I know that integrating Parts into SCons is planned (eventually).  As far trying to make an actual plan, do you think it can be integrated in sections or will it need to be wholesale.  I haven't looked at the code.

V/R,
William

On Mon, Jun 15, 2015 at 10:25 AM, Kenny, Jason L <jason.l.kenny at intel.com<mailto:jason.l.kenny at intel.com>> wrote:
Hi,

Just to clarify and add to Vasily comments ( Thank you Vasily). SCons provides the base building block for pretty much what you need. Parts adds a component model and a structure to help make it easier to do stuff. Parts provides a structure for how certain thing are done, so different components can work together better. This is differs from a "raw" scons build in which you can do whatever you want and because of that different Sconstruct may not work the same or well with each other. This is really no different than what can happen in Make. In Parts you define a SConstruct which defines the set of things you want to build. In many ways you can view it as the "Product" and the Parts calls are the components that make up the product. Parts adds some dependency management between components ( such as Parts A depends on Parts B version x.y.z) and allow for items such as the .a file name and path to be implicitly passed to avoid the user having to update many different build files with an updated so or .a lib file name. Parts also provides a common command like target structure to make it easier to control which component(s) are built. Parts does more than this, and does it by extending SCons vs replacing it. I know from certain people at work there are a few items Parts needs to improve on to help more with clusters, and these changes will come as resource to fix them become a available. Still everything in Parts is override-able on the command line, a config file ( needs more work however for certain cases), and the environment via a variable SCons supports.

The current working drop of this as at http://parts.tigris.org/
However this code is being moved to https://bitbucket.org/sconsparts While the code here is here is the latest is greatest ( however it might not be 100% stable). The work to clean up the new area is not finished yet. But feel free to add issues or questions on the site.

Jason

-----Original Message-----
From: Scons-users [mailto:scons-users-bounces at scons.org<mailto:scons-users-bounces at scons.org>] On Behalf Of Ray Sheppard
Sent: Saturday, June 13, 2015 4:15 PM
To: just.one.man at yandex.ru<mailto:just.one.man at yandex.ru>; SCons users mailing list; Paweł Tomulik
Subject: Re: [Scons-users] SCons popularity
Hi All,
   For what it is worth, without this functionality, use of SCons on supercomputers is problematic.
           Ray

On 6/13/2015 10:44 AM, Vasily wrote:
>
> Yes, I was talking about those. I believe you can override their
> default values by passing them as arguments, like $ scons all
> INSTALL_ROOT=some-path
>
> That would need some testing, though - I did not try setting it to a
> directory *not* under SConstruct's directory.
>
> Thanks,
> Vasily
>
>

_______________________________________________
Scons-users mailing list
Scons-users at scons.org<mailto:Scons-users at scons.org>
https://pairlist4.pair.net/mailman/listinfo/scons-users
_______________________________________________
Scons-users mailing list
Scons-users at scons.org<mailto:Scons-users at scons.org>
https://pairlist4.pair.net/mailman/listinfo/scons-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20150615/bbbcd472/attachment-0001.html>