Re: [Scons-dev] New symlink copy support

On Wed, Jul 30, 2014 at 3:43 AM, William Blevins wrote: >> 2. Get Mercurial and run tests in VM >> hg clone http://selenic.com/hg >> cd hg/contrib/vagrant >> vagrant up >> vagrant ssh -c ./run-tests.sh >> >> Vagrant mounts current folder as /vagrant inside VM, so when I cd

[Scons-dev] SCons learning curve (Was: New symlink copy support)

On Wed, Jul 30, 2014 at 3:16 AM, William Deegan wrote: > William, > > Yes that is used for VariantDir’s.. > There’s also an argument to such: > > BuildDir(build_dir, src_dir, [duplicate]) , env.BuildDir(build_dir, src_dir, > [duplicate]) > Deprecated synonyms for VariantDir and env.VariantDir(). T

Re: [Scons-dev] New symlink copy support

No, my suggestion is that license file is updated with the names of contributors, including Intel copyright line. On Tue, Jul 29, 2014 at 10:07 PM, Kenny, Jason L wrote: > So your suggestion is that I update the license file with Scons Foundation? > > Jason > > -Original Message- > From:

[Scons-dev] Test failures with biblattex

Can someone who understands latex and these tests take a look at the failures on buildbot? http://buildbot.scons.org:8010/builders/fedora7-python-2.7/builds/126/steps/shell/logs/stdio test/TEX/biber_biblatex.py test/TEX/biber_biblatex2.py test/TEX/biblatex.py test/

Re: [Scons-dev] New symlink copy support

> > 2. Get Mercurial and run tests in VM > hg clone http://selenic.com/hg > cd hg/contrib/vagrant > vagrant up > vagrant ssh -c ./run-tests.sh > > Vagrant mounts current folder as /vagrant inside VM, so when I cd to this > folder and try to create symlink, I get a nasty err

Re: [Scons-dev] New symlink copy support

William, Yes that is used for VariantDir’s.. There’s also an argument to such: BuildDir(build_dir, src_dir, [duplicate]) , env.BuildDir(build_dir, src_dir, [duplicate]) Deprecated synonyms for VariantDir and env.VariantDir(). The build_dir argument becomes the variant_dir argument of VariantDi

Re: [Scons-dev] New symlink copy support

Is SCons option "--duplicate=DUPLICATE" used to control Variant copying behavior? Seems that SCons already has functionality equivalent to CCopy that could utilized for Copy. V/R, William On Tue, Jul 29, 2014 at 7:27 PM, William Blevins wrote: > I can't foresee any situation where global swit

Re: [Scons-dev] New symlink copy support

> > I can't foresee any situation where global switch will be useful, but > it may be worthy to set one. I hope our goal is to to have intelligent > and fast build system, not the one creeping with options. So if we can > make automatic defaults that work fast thanks to symlinks where this > is sup

Re: [Scons-dev] New symlink copy support

So your suggestion is that I update the license file with Scons Foundation? Jason -Original Message- From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of anatoly techtonik Sent: Tuesday, July 29, 2014 12:21 PM To: SCons developer list Subject: Re: [Scons-dev] New symlink cop

Re: [Scons-dev] Pleased to announce we've added Dirk Bächle as a comitter to the core scons repo

On 29.07.2014 03:30, Manuel wrote: Cool that's great news!! El jul 28, 2014 9:46 PM, "Kenny, Jason L" > escribió: Second that! *From:*Scons-dev [mailto:scons-dev-boun...@scons.org ] *On Behalf Of *William Blevins

Re: [Scons-dev] New symlink copy support

On Tue, Jul 29, 2014 at 4:02 AM, Kenny, Jason L wrote: > Ideally that is the hope I have.. CCopy should be used as the backbone of > all copied in Parts and I hope in SCons. Everything in Parts is done so it > could be added to SCons. The license is MIT under Intel, but it is assumed > that SCons

Re: [Scons-dev] New symlink copy support

On Tue, Jul 29, 2014 at 2:39 AM, William Blevins wrote: >> > I think it is reasonable for SCons to support symlinks on systems that >> > support symlinks. >> It is not the matter of supporting, it is the matter of using them by >> default. >> You need to check FS support - not operating systems su

Re: [Scons-dev] New symlink copy support

On Mon, Jul 28, 2014 at 6:25 PM, Kenny, Jason L wrote: > Anatoly, > > What is your take on the CCopy behavior in Parts. I believe this addresses > the issue you are concern over. The logic be default is to do a > hard-soft-copy which is to say make a hard link, else symlink, else full copy. My

Re: [Scons-dev] Pleased to announce we've added Dirk Bächle as a comitter to the core scons repo

Gratz, Dirk! =) On Mon, Jul 28, 2014 at 10:16 PM, Bill Deegan wrote: > Greetings, > > Gary & I are please to announce we've added another user to the commit list > for the core scons repo. > > Dirk Bächle has been a long time participant in the SCons project both in > adding code and supporting