[Scons-users] Building in custom directory and relative paths to source files?

[Managan, Rob]

I agree with this in principle but this would require extensive testing
with the TeX builders. As I recall, the various tex Unix tools are rather
brain dead about directories. That is why the cd ${TARGET.dir}Š is put
into the command line. I believe this is done so that the tex output files
are in the same directory as the input file so that auxiliary tools like
bibtex and makeindex will work.

Now tools like dvips and dvipdf should be made to work in more general
situations as long as they don't break their usage with TeX which is their
primary usage. 

Hope this helps.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Rob Managan                             email managan at llnl.gov
LLNL                                             phone: 925-423-0903
P.O. Box 808, L-095                   FAX:   925-422-3389
Livermore, CA  94551-0808





On 4/20/13 9:07 AM, "Pawel Tomulik" <ptomulik at meil.pw.edu.pl> wrote:


>Well, some built in tools contain ${SOURCE.file}, for example tex.py,

>dvips.py, dvipdf.py, rpcgen.py m4.py have this. I haven't checked them

>all, but the described problem seems to exist in 'dvipdf', for example:

>

>   # SConstruct

>   env = Environment()

>   env.PDF('out/foo.pdf', 'foo.dvi')

>

>yields

>

>   ptomulik at barakus:$ scons -Q

>   cd out && dvipdf foo.dvi foo.pdf

>   dvips: DVI file can't be opened: foo.dvi: No such file or directory

>

>(unfortunately this produces target file out/foo.pdf, so it's hard to

>write good tests for this particular tool).

>

>The proposed changes, if safe enough, could be introduced to the core

>builders. If not, then maybe an appropriate techniques could be

>recommended in some guidelines for new tools?

>

>W dniu 20.04.2013 16:51, Gary Oberbrunner pisze:

>> Hi Pawel; which builders are you talking about?  Built-in ones?

>>

>>

>> On Sat, Apr 20, 2013 at 10:26 AM, Pawel Tomulik <ptomulik at meil.pw.edu.pl

>> <mailto:ptomulik at meil.pw.edu.pl>> wrote:

>>

>>     Hi,

>>

>>     I've seen that several builders use commands such as:

>>

>>     'cd ${TARGET.dir} && $FOOCOM ${SOURCE.file} ${TARGET.file}'

>>

>>     This seems to put the restriction that SOURCE and TARGET both must

>>lie

>>     in same directory. If so, then is there something against using

>>     'rel_path' for example?

>>

>>     'cd ${TARGET.dir} && $FOOCOM ${TARGET.rel_path(SOURCE)}

>>${TARGET.file}'

>>

>>     In theory it shouldn't alter existing projects (TARGET and SOURCE in

>>     same directory). It could, however, enable different directories for

>>     SOURCE and TARGET, and perhaps VariantDir (with duplicate=0) for

>>some

>>     tools which donot support them at the moment.

>>

>>     What do you think about it?

>>

>>     Another related question - is there any built in method to achieve

>>     similar goal (relative paths) when lists are substituted (SOURCES,

>>     TARGETS for example)? I think about something as:

>>

>>     '$FOCOM ${_concat("",SOURCES,"",__env____,RelTo(TARGET))}'

>>

>>     where 'RelTo' is the method of question?

>>

>>     Best regards!

>>