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 b...@baddogconsulting.com 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 users and triaging bugs. This adds some more depth to the list of committers so the project can continue to move forward even when some of us are unavailable for periods of time. - Bill Gary SCons project co-managers ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] New symlink copy support
On Mon, Jul 28, 2014 at 6:25 PM, Kenny, Jason L jason.l.ke...@intel.com 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 take is that's the way to go if we are making this Copy logic implicit. If there is a fallback mechanism then there won't be any issues. The code allow the user to explicitly set the copy logic for the whole build and allow a given copy to be set to have exact semantics the user wants independent of what the whole build is set to. 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 supported without breaking former logic - I am all +1. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] New symlink copy support
On Tue, Jul 29, 2014 at 2:39 AM, William Blevins wblevins...@gmail.com 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 support to make
it work without pain by default. There are many cases where people use
virtual machines to build stuff on different systems and source directory
often gets shared with network protocol that doesn't support symlinking
even if os supports it.
If someone is creating symlinks for code intended to be placed in a shared
directory with a Windows O/S, shame on them? Does this happen in software
you maintain or is this hypothetical?
I am taking about directories shared with Virtual Machines. I don't have
example with SCons at the moment, but these are two real world examples
wit Vagrant for you to try. It won't take a lot of time.
1. Get your own instance of http://bugs.python.org/ for hacking
https://bitbucket.org/techtonik/pydotorg-bpo
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 error:
vagrant ssh
$ cd /vagrant
$ ln config.yml config.yml2
ln: failed to create hard link `config.yml2' = `config.yml':
Operation not permitted
$ ln -s config.yml config.yml2
ln: failed to create symbolic link `config.yml2': Protocol error
$ python -c import os; os.symlink('config.yml', 'config.yml2')
Traceback (most recent call last):
File string, line 1, in module
OSError: [Errno 71] Protocol error
I am afraid the complain would be for SConstruct authors, not for SCons.
Obviously. I think we all eat our own dog food? I imagine this will affect
few developers adversely. This adds new capability for symlinks which
matches the Python API way of handling symlinks.
Thinking about Python API in a positive way is a trap. Knowing the pitfalls
is a path to salvation. If our CCopy approach works, we may propose it for
inclusion.
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
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 jason.l.ke...@intel.com mailto:jason.l.ke...@intel.com escribió: Second that! *From:*Scons-dev [mailto:scons-dev-boun...@scons.org mailto:scons-dev-boun...@scons.org] *On Behalf Of *William Blevins *Sent:* Monday, July 28, 2014 7:34 PM *To:* SCons developer list *Subject:* Re: [Scons-dev] Pleased to announce we've added Dirk Bächle as a comitter to the core scons repo Yeah Dirk! Thanks guys! :) Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
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 copy support On Tue, Jul 29, 2014 at 4:02 AM, Kenny, Jason L jason.l.ke...@intel.com 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 will own all this code as it moves stuff over. Intel has no interest in controlling a build system. As long as license is MIT, there is no need to transfer copyright. Just add the appropriate line to LICENSE file. In fact, I prefer this way of doing things, like in Twisted. https://twistedmatrix.com/trac/browser/trunk/LICENSE Then at the top of each file we just reference the LICENSE. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
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 supported without breaking former logic - I am all +1. I personally think a global switch would be very convenient if you don't like the default behavior. Options are fine if they are handled like scons --debug=items so the options are well categorized. I agree that a lot of base level options can be scary though. It may not break previous logic, but it may not have the desired effect. The difference is subtle, but could be even harder to troubleshoot. I do think the original effort should have been to do this in the first place. I didn't know it existed until after the changes had been discussed, reviewed, and merged. V/R, William On Tue, Jul 29, 2014 at 12:51 PM, anatoly techtonik techto...@gmail.com wrote: On Mon, Jul 28, 2014 at 6:25 PM, Kenny, Jason L jason.l.ke...@intel.com 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 take is that's the way to go if we are making this Copy logic implicit. If there is a fallback mechanism then there won't be any issues. The code allow the user to explicitly set the copy logic for the whole build and allow a given copy to be set to have exact semantics the user wants independent of what the whole build is set to. 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 supported without breaking former logic - I am all +1. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
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 VariantDir or env.VariantDir(). Note you’ll find more detail in the manpage: http://scons.org/doc/production/HTML/scons-man.html Search for VariantDir(). If you’re going to use SCons in any significant way, a thorough read of the manpage and user guide will serve you well. -Bill On July 29, 2014 at 5:06:30 PM, William Blevins (wblevins...@gmail.com) wrote: 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 wblevins...@gmail.com wrote: 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 supported without breaking former logic - I am all +1. I personally think a global switch would be very convenient if you don't like the default behavior. Options are fine if they are handled like scons --debug=items so the options are well categorized. I agree that a lot of base level options can be scary though. It may not break previous logic, but it may not have the desired effect. The difference is subtle, but could be even harder to troubleshoot. I do think the original effort should have been to do this in the first place. I didn't know it existed until after the changes had been discussed, reviewed, and merged. V/R, William On Tue, Jul 29, 2014 at 12:51 PM, anatoly techtonik techto...@gmail.com wrote: On Mon, Jul 28, 2014 at 6:25 PM, Kenny, Jason L jason.l.ke...@intel.com 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 take is that's the way to go if we are making this Copy logic implicit. If there is a fallback mechanism then there won't be any issues. The code allow the user to explicitly set the copy logic for the whole build and allow a given copy to be set to have exact semantics the user wants independent of what the whole build is set to. 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 supported without breaking former logic - I am all +1. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
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 error:
vagrant ssh
$ cd /vagrant
$ ln config.yml config.yml2
ln: failed to create hard link `config.yml2' = `config.yml':
Operation not permitted
$ ln -s config.yml config.yml2
ln: failed to create symbolic link `config.yml2': Protocol error
$ python -c import os; os.symlink('config.yml', 'config.yml2')
Traceback (most recent call last):
File string, line 1, in module
OSError: [Errno 71] Protocol error
I've never used vagrant before, but it was fairly intuitive with your
example.
1. run-tests.sh is still executing after 30min+ and there are some errors,
but nothing I can see related to symlinks.
2. I was able to create symlinks inside the /vagrant directory
Based on this example, I don't think your use case makes sense. In order
for the SCons Copy code to fail on os.symlink, Copy must be attempting to
copy a symlink:
ls -l
lrwx-- item - item.txt
-rwx-- item.txt
cat SConstruct
Copy( 'item', 'item_link', True ) # default is True anyway
Copy( 'item', 'item_file', False ) # default is True anyway
scons
Copy( item, item_link )
Copy( item, item_file )
ls -l
lrwx-- item - item.txt
-rwx-- item.txt
lrwx-- item_link - item.txt
-rwx-- item_file
echo item.txt item_file inode count is 1
Copy does not try to create a symlink from a real file:
ls -l
-rwx-- item.txt
cat SConstruct
Copy( 'item.txt', 'item_copy', True ) # default is True anyway
scons
Copy( item.txt, item_copy )
ls -l
-rwx-- item.txt
-rwx-- item_copy
echo item.txt item_copy inode count is 1
Since the filesystem in the example does not support symlinks (I assume),
then SCons will not be trying to copy a symlink anyway.
Maybe it was just a bad example? You could still have this issue if you are
copying a symlink from a filesystem that supports it to one that doesn't.
V/R,
William
On Tue, Jul 29, 2014 at 1:13 PM, anatoly techtonik techto...@gmail.com
wrote:
On Tue, Jul 29, 2014 at 2:39 AM, William Blevins wblevins...@gmail.com
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 support to make
it work without pain by default. There are many cases where people use
virtual machines to build stuff on different systems and source
directory
often gets shared with network protocol that doesn't support symlinking
even if os supports it.
If someone is creating symlinks for code intended to be placed in a
shared
directory with a Windows O/S, shame on them? Does this happen in software
you maintain or is this hypothetical?
I am taking about directories shared with Virtual Machines. I don't have
example with SCons at the moment, but these are two real world examples
wit Vagrant for you to try. It won't take a lot of time.
1. Get your own instance of http://bugs.python.org/ for hacking
https://bitbucket.org/techtonik/pydotorg-bpo
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 error:
vagrant ssh
$ cd /vagrant
$ ln config.yml config.yml2
ln: failed to create hard link `config.yml2' = `config.yml':
Operation not permitted
$ ln -s config.yml config.yml2
ln: failed to create symbolic link `config.yml2': Protocol error
$ python -c import os; os.symlink('config.yml', 'config.yml2')
Traceback (most recent call last):
File string, line 1, in module
OSError: [Errno 71] Protocol error
I am afraid the complain would be for SConstruct authors, not for SCons.
Obviously. I think we all eat our own dog food? I imagine this will
affect
few developers adversely. This adds new capability for symlinks which
matches the Python API way of handling symlinks.
Thinking about Python API in a positive way is a trap. Knowing the pitfalls
is a path to salvation. If our CCopy approach works, we may propose it for
inclusion.
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
[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/TEX/biblatex_plain.py Thanks, Bill ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
