[M3devel] aclocal.m4

[Jay]

"This stuff" is mostly disabled by lack of -enable-maintainer-mode
on the configure command line.
In most of the Makefiles there is @MAINT@ which by default evaluates to a comment.
Mpfr doesn't do it this way.
Maybe due to different versions of auto tools?
That's what I know so far..
 
 - Jay

________________________________
> From: jay.krell at cornell.edu
> To: rodney.bates at wichita.edu; m3devel at elegosoft.com
> Subject: RE: [M3devel] aclocal.m4
> Date: Sun, 1 Mar 2009 19:31:56 +0000
>
>
>
>
>
>
>
>
> Probably you have auto* tools installed, and the timestamps are messed up somewhere, such that more stuff is being built. Similarly I used to always see the documentation get rebuilt in my builds, really fouling up cvs diff. I fixed that by having m3makefile say stuff like MAKEINFO=: (colon is an empty command). I never tracked down why the build steps were running which generally aren't supposed to, unless you edit files that "we" don't edit.
>
>
>
>
>
> Tangentially: gmp and mpfr are a significant fraction of building gcc. I wonder if we can't be smarter here..if /usr/local/lib/libgmp.a exists, tell configure not to build it, or somesuch.
>
>
>
> Back on topic. Most of you probably know this but just in case:
>
> In many projects in the wider Unixish/GNUish world, there are a lot of a certain class of checked in "derived" files. "Derived" being the Modula-3 term for "built" or "machine generated" or "compiler output", etc. "Derived" files are usually "binary", like .o files, but they can also be text files. For example, when you run configure it produces Makefile and config.h.
>
> The configure sh program is actually a "derived" file, from something like configure.ac.
>
> Makefile (not usually checked in) is derived from Makefile.in (usually checked in), which is often derived from Makefile.am.
>
> Now, further afield..from there are documentation-related checked in files, and the file you point out Rodney is probably generated.
>
> Another good example is people often checkin the output of lex or yacc, so that build who only have a C compiler/linker but not lex or yacc can build the software.
>
>
>
> Generally in source control the checked in derived files have a newer timestamp than their source files, so a build will "naturally" not try to build them.
>
> Often these files have "additional build dependencies" such as needing perl installed, that the project does not wish to foist upon everyone.
>
>
>
> So that's the background possibly all redundant.
>
>
>
> The questions boil down to:
>
> - What is up with the timestamps?
>
> I don't mean just on your machine Rodney. I generally don't have a full auto* toolset installed. I haven't figured out how is supposed to have a variety of versions installed /and/ have the Makefile pick the right one. I can all them all to separate -prefix, but that doesn't solve it.
>
> So, that implies why I don't see this exact case, but as I said, I used to see with this a bunch of other files.
>
>
>
> - You see it for other files too?
>
>
>
> - Other folks see it?
>
>
>
> - Is there a simple hack like I did for makeinfo that can quash it? I'll see.
>
>
>
> I guess I can just install latest autotools and see what happens.
>
>
>
>
>
> - Jay
>
>
>
>> Date: Sun, 1 Mar 2009 11:30:41 -0600
>> From: rodney.bates at wichita.edu
>> To: m3devel at elegosoft.com
>> Subject: [M3devel] aclocal.m4
>>
>> What is the story on m3-sys/m3cc/gcc/mpfr/aclocal.m4? The cvs repository has a
>> copy that is always empty and I always have a local copy with a lot of stuff
>> in it, giving a lot of cvs diff output that makes it look like I made local
>> changes. It this file always generated during the build process? Should it
>> be removed from the repository?
>>
>> Rodney Bates