lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use mkstemp for intermediate ps files (issue 233230044 by address@hi


From: David Kastrup
Subject: Re: Use mkstemp for intermediate ps files (issue 233230044 by address@hidden)
Date: Fri, 08 May 2015 10:51:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Masamichi HOSODA <address@hidden> writes:

>> what happens if I set delete-intermediate-file to ##f?
>> Will the temporary PS file be renamed or copied to '<name>.ps'?
>
> No.
>
> Temporary PS file will be created in the temporary directory,
> instead of current directory.
>
> If you set delete-intermediate-file to ##f,
> lilypond will not delete the temporary file in the temporary directory.
>
>> Background:
>> I'm often compiling LY files using this option, because besides the PDF
>> created by lilypond I create another file from data in the PS file (in a
>> batch process after lilypond has been executed) - and I start up to 8
>> lilypond processes for parallel execution if I want to 'update' all PDFs of
>> a lilypond project.
>
> When you want both PDF and PS files,
> I recommend the following command.
>
> $ lilypond --pdf --ps <name>.ly

The corresponding GCC option leaves the respective files in place, with
the documentation warning about concurrency issues.

'-save-temps'
'-save-temps=cwd'
     Store the usual "temporary" intermediate files permanently; place
     them in the current directory and name them based on the source
     file.  Thus, compiling 'foo.c' with '-c -save-temps' produces files
     'foo.i' and 'foo.s', as well as 'foo.o'.  This creates a
     preprocessed 'foo.i' output file even though the compiler now
     normally uses an integrated preprocessor.

     When used in combination with the '-x' command-line option,
     '-save-temps' is sensible enough to avoid over writing an input
     source file with the same extension as an intermediate file.  The
     corresponding intermediate file may be obtained by renaming the
     source file before using '-save-temps'.

     If you invoke GCC in parallel, compiling several different source
     files that share a common base name in different subdirectories or
     the same source file compiled for multiple output destinations, it
     is likely that the different parallel compilers will interfere with
     each other, and overwrite the temporary files.  For instance:

          gcc -save-temps -o outdir1/foo.o indir1/foo.c&
          gcc -save-temps -o outdir2/foo.o indir2/foo.c&

     may result in 'foo.i' and 'foo.o' being written to simultaneously
     by both compilers.

'-save-temps=obj'
     Store the usual "temporary" intermediate files permanently.  If the
     '-o' option is used, the temporary files are based on the object
     file.  If the '-o' option is not used, the '-save-temps=obj' switch
     behaves like '-save-temps'.

     For example:

          gcc -save-temps=obj -c foo.c
          gcc -save-temps=obj -c bar.c -o dir/xbar.o
          gcc -save-temps=obj foobar.c -o dir2/yfoobar

     creates 'foo.i', 'foo.s', 'dir/xbar.i', 'dir/xbar.s',
     'dir2/yfoobar.i', 'dir2/yfoobar.s', and 'dir2/yfoobar.o'.


That's probably the most desirable manner of operating: when the files
are supposed to stay around, random file names are not likely to help a
lot.

Even though in this particular use case, the advice of using proper
target format options rather than the delete-intermediate-file option
(which is more for the sake of debugging) seems preferable.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]