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

[Pawel Tomulik]

W dniu 22.04.2013 18:11, Managan, Rob pisze:

> 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.



Right, I don't mean to touch the cd ${TARGET.dir} - it should be left as
is. The change from ${SOURCE.file} to something like
${TARGET.rel_path(SOURCE)} shouldn't break existing projects but may
give more flexibility to new ones. More generally, tools could define
variables such as $FOOCHDIR (e.g. FOOCHDIR="$TARGET") and then use
convention

FOOCOM = 'cd $FOOCHDIR && $FOO ${FOOCHDIR.rel_path(SOURCE)} 
${FOOCHDIR.rel_path(TARGET)}'



> 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.


Ok. Fortunately it seems that tex/latex builders already handle
correctly builds with source file outside of target/build directory, so
they may be left as is. It seems like these builders ensure internally 
that source and target files are in same directory when latex is invoked 
(I don't know how, maybe they copy files somewhere,
before doing the job).


>

> 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.


It shouldn't break, as long as their usage (with TeX) sticks to the
convention that sources and targets (appearing in builder arguments) are
in same directory.


>

> 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!

>>>

>

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users

>



-- 
Paweł Tomulik