[Top][All Lists]

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

Re: Extending default suffix rules.

From: Remco Bras
Subject: Re: Extending default suffix rules.
Date: Sun, 2 Mar 2008 19:01:39 +0100
User-agent: KMail/1.9.6 (enterprise 0.20070907.709405)


> * Remco Bras wrote on Sun, Mar 02, 2008 at 03:39:57PM CET:
> > Op Sunday 02 March 2008 15:20:42 schreef Ralf Wildenhues:
> > > Your rule is dangerous.  If the user interrupts make at the time the
> > > script has run but the backup hasn't been restored yet,
> > > the source will be wrong, and the next time you may have duplicate
> > > function definitions (or whatnot else the sed script then does given
> > > the wrong input file).
> >
> > Fortunately, the sed script only fires on things matching the patterns
> > convertors(type); or convertors(type,display_name_of_type);, not on the
> > expansion (which is a pair of normal C99 function definitions). If it
> > did, the same issues would arise if the gcc couldn't compile the
> > generated file.
> But the interruption could also happen during the execution of
>   cp $<{.backup,}
> In that case, your innocent user will have an incomplete file and may
> see weird errors later.  For maximum safety, any conversion scripts or
> copies should first copy to a temporary file (inside the build tree)
> and then mv atomically to the output file.  That way, even SIGQUIT
> (CTRL-\) will not leave partial files (upon SIGINT, make will remove the
> target file of the rule that is currently executed).
> BTW, the {...,} is a bash extension and not POSIX compatible.
I'll keep that in mind, though in the newer version, the only thing that can 
happen is that is interrupted and the user is left with a bogus 
generated C file. Such files are cleaned up by make clean, though make would 
choke on any bogus that is already present, so perhaps I should indeed take 
care to work around that issue by copying to .c.tmp first and mv'ing later.
To my knowledge, my shell scripts do not use any bash specifics, but I'm far 
from an expert.

> > I do like the option of using a different suffix, since it alerts any
> > contributor that whatever is in there may, in certain areas, not be
> > standard C. Also, it isolates any non-portability in the pre-processing
> > process, allowing the C that is generated to be compiled portably.
> > Avoiding any possible issues of macros that generate expansions that
> > could be invocations of themselves is a side benefit, but welcome.
> I forgot earlier about the issue with distribution.  For the generated
> stuff, you should either use nodist_foo_SOURCES and also
>   CLEANFILES = $(nodist_foo_SOURCES)
Currently, I'm using a clean-local target and some other trickery to keep 
track of what is generated and delete it on make clean, but perhaps a more 
regular approach could be helpful, I'll have a look at the relevant manual 

Thanks yet again,


reply via email to

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