Latex project with parent-child files

[Russel Winder]

On Fri, 2011-08-12 at 13:46 +0900, Stephen J. Turnbull wrote:
[ . . . ]
>  > Russel, I'm not familiar with Waf nor SCons.
> 
> These are build dependency management software.  The traditional tool
> on Unix is called "make".  The basic problem is that you may have
> generated files for your document (such as graphs).  Doing the work of
> generating them every time is time-consuming, ie, slows down the
> edit-generate-review cycle.  Make-like tools help minimize the work
> done in generating your document, thus speeding up the process.

Make though is very platform dependent because the dependency language
is separate from the action language (external DSL).  Hence CMake.  Waf
and SCons  are Python based systems such that the action language and
the dependency language are the same (internal DSL).  This makes Waf and
SCons far more portable.  Plus they have far superior built-in handling
of LaTeX build.  (Rake, etc. provide the dependency management as an
internal DSL and then leave you to deal with all your own action rules
-- unless you are managing Ruby applications.)  

> Probably MikTeX handles the basics for you already, though.  Does
> MikTex ever produce output that does *not* reflect some change or
> addition you've made to the document?  If the answer is "no", you
> don't *need* Waf or SCons.  (Though you may find them useful in
> projects where you want more automation than MikTeX provides -- if
> you've got a little time, you might want to investigate them.)

As far as I know (I don't use Windows) MikTeX is just a packaging of
(La)TeX for Windows, it doesn't provide tooling other than a previewer.
Think an "easy to install on Windows" version of TeXLive.  Except that
MikTeX has an auto installing package manager which sounds very cool.

I am not sure if TeXWorks comes bundled in MikTeX as it does in MacTex
and is packaged for Debian.

>  > I understand it doesn't create all those annoying Tex process
>  > files. What else?
> 
> That's probably not a benefit.  TeX creates the TeX process files.
> (It's possible that MikTeX allows you to generate one chapter at a
> time, in which case you would get fewer files because make-like tools
> are more or less designed for processing the whole document every
> time, but skipping steps that were already done the last time.)
> 
> However, if you are working in a MikTeX interface for TeX and Bazaar
> Explorer for version control, I don't see why you should care about
> the auxiliary files.  MikTeX should suppress listing of .aux, .dvi,
> and .log files unless you ask for them, and Bazaar Explorer will do
> the same if you add a .bzrignore file with three lines
> 
> *.aux
> *.dvi
> *.log

If you are using makeindex or bibtex there are a whole load more extra
generated files you want to ignore as far as Bazaar is concerned.

I do not ignore them though as it shows when I haven't cleaned a
project.  I find it far easier to recreate all the generated files when
I sit down for a session, and then remove them all at the end of that
session.  Even for a complex 700 page book creation time is very short
and leaving files lying round just isn't worth it.

I can see in the days before sensible build support a different work
process was valid, but these days, it is much easier to use the tools
rather than leave stuff lying around. 

> in it to the top folder of your project.  Of course if you get a file
> listing from the command shell or the GUI desktop file manager, you
> get all the gory details.  Then for the command shell, "bzr ls" will
> DTRT, and as for using the file manager, "the doctor says, 'if it
> hurts, just stop doing that!'" :-)  Just get used to using Bazaar
> Explorer instead.

Unless you are a command line addict as I am in which case "bzr glog" is
about the only GUI tool I use for Bazaar.

> 
> Footnotes: 
> [1]  A project where for some reason multiple versions of the same
> content are in development at the same time.  For example, in the case
> of a dissertation, you may have a chapter which you are simultaneously
> submitting for publication.  Your examiners will likely demand a "fat"
> discussion proving you know everything about the subject, while the
> journal editor will insist on a "lean" discussion, assuming that the
> reader knows almost everything and you just tell her the news.  It's
> not clear to me that existing VCSes can help you much with this
> particular case, but that's the kind of thing branches help manage.

That sounds like two different documents that originally shared some
material to me rather than variants of the same project.   I would
advise two branches, one for the dissertation and one for the paper and
use a merge tool to deal with keeping common material in sync.



-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110812/b4eda67f/attachment.pgp>