Build: Try to convince `make' to keep intermediate files.

Build: Try to convince `make' to keep intermediate files.

Possible fix to issue 1906.

[Julien Rioux, 2011-12-19 23:37:53]

This could possibly fix the recurring issues with parallel make. However if
`make -jX' does not obey the .SECONDARY: construct then we are not any better
off.

[Keith, 2011-12-21 07:42:41]

Works with no problem on my (single-processor) Fedora system, for what little
that is worth.

Could you point out which files are affected by .SECONDARY, Julien, so users of
the affected systems might test specifically to see if this addresses their
problem?

The machine-generated parser.cc, for example, is not deleted by make either with
or without your patch.

[mail_philholmes.net, 2011-12-21 09:22:17]

----- Original Message ----- 
From: <julien.rioux@gmail.com>
To: <julien.rioux@gmail.com>
Cc: <reply@codereview-hr.appspotmail.com>; <lilypond-devel@gnu.org>
Sent: Monday, December 19, 2011 11:37 PM
Subject: Build: Try to convince `make' to keep intermediate files. 
(issue5490077)



A general comment on changes to the build system.  How do we know that 
there's been no unintended other effects of changes like this?  I think it 
would be wise to work up a system of checking, by doing something like 
creating a list of all the files created by a build, applying the changes, 
and then checking for diffs.

Thoughts?

--
Phil Holmes

[Graham Percival, 2011-12-21 15:18:26]

On Wed, Dec 21, 2011 at 09:22:11AM -0000, Phil Holmes wrote:
> A general comment on changes to the build system.  How do we know
> that there's been no unintended other effects of changes like this?
> I think it would be wise to work up a system of checking, by doing
> something like creating a list of all the files created by a build,
> applying the changes, and then checking for diffs.

As long as patchy can do a full doc rebuild from scratch (done
before accepting staging), and GUB can release stuff, I'm happy
with that risk.  I mean, it's not impossible that something might
still go wrong, but I figure that most potential mistakes would be
caught in that process.

If you really want to be safe, you could certainly do something
like
  ls -R $HOME/lilypond-git/build   >  old-build-files.txt
... edit, patch, delete build dir, do full doc build...
  ls -R $HOME/lilypond-git/build   >  new-build-files.txt
  diff old-build-files.txt new-build-files.txt

If they differ, you might have a problem.  But when you're adding
new log files, you'd expect those to be added, so manual attention
at the diff stage is required.

I think such a script should just be used by you locally; I don't
see enough demand/danger to warrant trying to add such a script to
Patchy.

Cheers,
- Graham

[mail_philholmes.net, 2011-12-21 15:24:52]

----- Original Message ----- 
From: "Graham Percival" <graham@percival-music.ca>
To: "Phil Holmes" <mail@philholmes.net>
Cc: <julien.rioux@gmail.com>; <lilypond-devel@gnu.org>; 
<reply@codereview-hr.appspotmail.com>
Sent: Wednesday, December 21, 2011 3:18 PM
Subject: Re: Build: Try to convince `make' to keep intermediate files. 
(issue5490077)


> On Wed, Dec 21, 2011 at 09:22:11AM -0000, Phil Holmes wrote:
>> A general comment on changes to the build system.  How do we know
>> that there's been no unintended other effects of changes like this?
>> I think it would be wise to work up a system of checking, by doing
>> something like creating a list of all the files created by a build,
>> applying the changes, and then checking for diffs.
>
> As long as patchy can do a full doc rebuild from scratch (done
> before accepting staging), and GUB can release stuff, I'm happy
> with that risk.  I mean, it's not impossible that something might
> still go wrong, but I figure that most potential mistakes would be
> caught in that process.
>
> If you really want to be safe, you could certainly do something
> like
>  ls -R $HOME/lilypond-git/build   >  old-build-files.txt
> ... edit, patch, delete build dir, do full doc build...
>  ls -R $HOME/lilypond-git/build   >  new-build-files.txt
>  diff old-build-files.txt new-build-files.txt
>
> If they differ, you might have a problem.  But when you're adding
> new log files, you'd expect those to be added, so manual attention
> at the diff stage is required.
>
> I think such a script should just be used by you locally; I don't
> see enough demand/danger to warrant trying to add such a script to
> Patchy.
>
> Cheers,
> - Graham
>

Agreed.  I think it's worth those of us messing with the build system 
getting used to running, though.

--
Phil Holmes

[Julien Rioux, 2011-12-22 04:38:20]

On Wed, Dec 21, 2011 at 2:42 AM,  <k-ohara5a5a@oco.net> wrote:
> Works with no problem on my (single-processor) Fedora system, for what
> little that is worth.
>
> Could you point out which files are affected by .SECONDARY, Julien, so
> users of the affected systems might test specifically to see if this
> addresses their problem?

One of the problem in addressing the various reports is precisely that
there is not specifically a single file that you can test for. But
generally if out.html is generated from out.texi which is generated
from in.texi, then make would consider out.texi an intermediate file
and would remove it. If it is specifically marked as a target of
.SECONDARY or .PRECIOUS then make will not remove it.

> The machine-generated parser.cc, for example, is not deleted by make
> either with or without your patch.

I think this is one of the files marked as .PRECIOUS

> http://codereview.appspot.com/5490077/