Re: [PATCH 1/5 v2] newlib: libm: move manual into top-level build
Jon Turney <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
On 01/02/2022 03:40, Mike Frysinger wrote: > On 31 Jan 2022 14:58, Jon Turney wrote: >> On 28/01/2022 07:58, Mike Frysinger wrote: >>> --- /dev/null >>> +++ b/newlib/libm/Makefile.inc >>> @@ -0,0 +1,26 @@ >>> +info_TEXINFOS += %D%/libm.texi >>> +%C%_libm_TEXINFOS = %D%/targetdep.tex $(LIBM_CHEWOUT_FILES) >>> + >>> +LIBM_CHEWOUT_FILES = >>> + >>> +LIBM_CHAPTERS = >>> + >>> +%D%/libm.dvi: %D%/targetdep.tex $(LIBM_CHEWOUT_FILES) >>> + >>> +%D%/targetdep.tex: $(LIBM_CHAPTERS) >>> + $(AM_V_GEN)cat $^ > [email protected] >>> + $(AM_V_at)$(SHELL) $(newlib_basedir)/../move-if-change [email protected] $@ >>> + $(AM_V_at)touch $@ >> >> We carefully only update $@ if it's changed, then touch it anyhow? >> >> This seems like a transcription error, since originally we were touching >> a timestamp file, or perhaps leftover from testing? > > you're right of course. i saw other places that weren't using the stamp > idiom, and then when rewriting these rules i remembered those places and > thought i wouldn't bother deploying the stamp pattern here since it was > already doing it wrong. but i misremembered which ones were wrong. > >> The same pattern occurs later, as well. > > which one do you mean ? the .xml ones ? those currently aren't using the > stamp idiom. or do you just mean the multiple places where targetdep.tex > is generated ? %D%/targetdep.tex rule in 3/5 %D%/libc.xml rule in 4/5 %D%/libm.xml rule in 4/5 > >>> --- a/newlib/libm/common/Makefile.am >>> +++ b/newlib/libm/common/Makefile.am >>> >>> -CHAPTERS = >>> +LIBM_CHEWOUT_FILES = >>> +LIBM_CHAPTERS = >>> +include ./Makefile.inc >> >> Is this boilerplate really needed before including the makefile >> fragment, since '+=' should work even if the variable isn't already defined? > > yes, automake enforces it Fair enough.