[Scons-users] SCons popularity

Sat Jun 20 10:51:24 EDT 2015

Jason,

Yes and no.  Is there a plan or roadmap? (EG. Step 1: migrate functions A,
Z into src/engine/SCons/Tool)

If we had such a roadmap, it might allow us to make program (slowly but
surely).  Right now it's more of a pie in the sky vision.

V/R,
William

PS: Might be a good idea to switch this convo to the dev listing.

On Mon, Jun 15, 2015 at 2:53 PM, Kenny, Jason L <jason.l.kenny at intel.com>
wrote:

>  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
> <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>
> 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] On Behalf Of Ray
> Sheppard
> Sent: Saturday, June 13, 2015 4:15 PM
> To: 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
> https://pairlist4.pair.net/mailman/listinfo/scons-users
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
>
> _______________________________________________
> Scons-users mailing list
> 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/20150620/84932cdd/attachment.html>