[Scons-dev] SCons learning curve (Was: New symlink copy support)
On Wed, Jul 30, 2014 at 3:16 AM, William Deegan b...@baddogconsulting.com 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(). 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.htmlSearch 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. Thorough read is a big design fail if you ask me. Tools for humans need to be intuitive, so I hope our goal is to get a tool that needs very short introduction to get going, and just a short reference for all major concepts. -- anatoly t. ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Test failures with biblattex
Hi Bill, For test/TEX/biber_biblatex.py we get: biber returned an error, check the blg file I suspect that the installed version of biber is mismstched with the version of biblatex and errors out. I guess I need to find a way to figure out what version of biber is installed and what version we require. At http://ctan.mirrorcatalogs.com/macros/latex/contrib/biblatex/doc/biblatex.pdf on page 6 I found the chart for what versions of biblatex and biber are compatible. I will email back later when I figure out how to get the version of biblatex. Probably a kpsewhich type call and then look at the top of the biblatex.sty file. I hope biber as an executable will tell you its version with a command line option. More when I get my ancient linux laptop up and running. Same for test/TEX/biber_biblatex2.py, test/TEX/biblatex.py, and test/TEX/biblatex_plain.py What version of fedora is that buildbot have installed by the way. I suspect it is not fedora7 as the name implies. Rob Managan ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] SCons learning curve (Was: New symlink copy support)
Anatoly, A manpage is supposed to be the definitive list of all the API’s. If you think you can do anything substantive with a system based on a cursory read of some short documentation, I believe you are mistaken. That said a trivial build doesn’t require a more complete comprehension of SCons. He’s working on an issue dealing with how variantdirs implemented based on an option. I think it’s reasonable that a good read of the manpage and at the very least searching the manpage for related terms is reasonable. -Bill On July 29, 2014 at 11:32:58 PM, anatoly techtonik (techto...@gmail.com) wrote: On Wed, Jul 30, 2014 at 3:16 AM, William Deegan b...@baddogconsulting.com 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(). 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.htmlSearch 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. Thorough read is a big design fail if you ask me. Tools for humans need to be intuitive, so I hope our goal is to get a tool that needs very short introduction to get going, and just a short reference for all major concepts. -- anatoly t. ___ 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] Test failures with biblattex
Dirk, What OS is your fedora7 buildbot slave running. Is it still Fedora 7? -Bill On July 30, 2014 at 7:11:30 AM, Managan, Rob (manag...@llnl.gov) wrote: Hi Bill, For test/TEX/biber_biblatex.py we get: biber returned an error, check the blg file I suspect that the installed version of biber is mismstched with the version of biblatex and errors out. I guess I need to find a way to figure out what version of biber is installed and what version we require. At http://ctan.mirrorcatalogs.com/macros/latex/contrib/biblatex/doc/biblatex.pdf on page 6 I found the chart for what versions of biblatex and biber are compatible. I will email back later when I figure out how to get the version of biblatex. Probably a kpsewhich type call and then look at the top of the biblatex.sty file. I hope biber as an executable will tell you its version with a command line option. More when I get my ancient linux laptop up and running. Same for test/TEX/biber_biblatex2.py, test/TEX/biblatex.py, and test/TEX/biblatex_plain.py What version of fedora is that buildbot have installed by the way. I suspect it is not fedora7 as the name implies. Rob Managan ___ 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] Test failures with biblattex
Hi, On 30.07.2014 19:05, William Deegan wrote: Dirk, What OS is your fedora7 buildbot slave running. Is it still Fedora 7? it's running Fedora17, as the info page correctly states: http://buildbot.scons.org/buildslaves/fedora-17 . It's just the slave's name that somehow (*cough*) got wrong. ;) Regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Test failures with biblattex
Dirk, I can change the name to 17 and restart if you can update the slave on your side? -Bill On Wed, Jul 30, 2014 at 10:57 AM, Dirk Bächle tshor...@gmx.de wrote: Hi, On 30.07.2014 19:05, William Deegan wrote: Dirk, What OS is your fedora7 buildbot slave running. Is it still Fedora 7? it's running Fedora17, as the info page correctly states: http://buildbot.scons.org/buildslaves/fedora-17 . It's just the slave's name that somehow (*cough*) got wrong. ;) Regards, Dirk ___ 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] Test failures with biblattex
On 30.07.2014 19:59, Bill Deegan wrote: Dirk, I can change the name to 17 and restart if you can update the slave on your side? -Bill Okay, let's do that. Do I have to change some config first, or do I restart the slave right away? Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Test failures with biblattex
On Wed, 2014-07-30 at 19:57 +0200, Dirk Bächle wrote: it's running Fedora17, as the info page correctly states: Isn't Fedora 17 just a teensy weensy bit out of date? (given Fedora 20 is current and 21 pending?) -- 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 http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Test failures with biblattex
Hi Russel, On 30.07.2014 22:18, Russel Winder wrote: On Wed, 2014-07-30 at 19:57 +0200, Dirk Bächle wrote: it's running Fedora17, as the info page correctly states: Isn't Fedora 17 just a teensy weensy bit out of date? (given Fedora 20 is current and 21 pending?) yes, but my understanding is that it's not required to always have the latest version of every OS running. I even regard it to be a little counter-productive for a system like Buildbot, which helps us to keep SCons working on a variety (!) of platforms. As long as Python 2.7 runs on it, the OS should be good enough for testing and actually working with it... Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] New symlink copy support
I see, I missed this fact from the commit. That makes sense,
but documentation needs to be simplified IMO.
https://bitbucket.org/scons/scons/commits/2e225b46b2ad10230ae0a11090a7a26101866989
Because I read symbolic link copying behavior in a wrong way.
Provide a suggestion? I can barely read my own mind much less anyone
else's :)
What about this?
+para
+The Copy; factory supports copying symbolic links. This behavior can
be controlled by an optional third argument.
+/para
+
+para
+Symbolic link shallow copied a new symbolic link:
+/para
+
+para
+literalCommand(LinkIn, LinkOut1, Copy($TARGET, $SOURCE[,
True]))/literal
+/para
+
+para
+Symbolic link target copied as a file or directory:
+/para
+
+para
+literalCommand(LinkIn, FileOrDirectoryOut, Copy($TARGET,
$SOURCE, False))/literal
+/para
V/R,
William
On Wed, Jul 30, 2014 at 2:48 AM, anatoly techtonik techto...@gmail.com
wrote:
On Wed, Jul 30, 2014 at 3:43 AM, William Blevins wblevins...@gmail.com
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 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
Sorry if I was not clear. This was just to demonstrate the modern
development setup with Vagrant. The type of file system mounted
as /vagrant is your host FS. In my case it is Windows, so I get
this error.
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:
I see, I missed this fact from the commit. That makes sense,
but documentation needs to be simplified IMO.
https://bitbucket.org/scons/scons/commits/2e225b46b2ad10230ae0a11090a7a26101866989
Because I read symbolic link copying behavior in a wrong way.
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.
Also in Windows you can not create link from one drive to other even
if FS supports it.
___
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
