Re: maintainer mode [was: Re: Building of generated parser files]

Re: maintainer mode [was: Re: Building of generated parser files]

[Richard Stallman]

Here is another idea.  When a distribution contains non-source files,
the makefile rules for these targets could be designed to check
checksums of them and the sources they were made from.  If these show
that a certain target file and the relevant sources are all unchanged
from the distribution versions, the rule would either do nothing, or
just touch the output file.

Re: HAVE_STDLIB_H

[Craig Burley]

>Well, at least short term the problem with this is only the
>c++ front end includes stdlib.h -- c, g77 and objc don't
>include it, and thus if autoconf decided that a decl wasn't
>needed because one existed in stdlib.h, then we end up losing.

FYI, my version of g77 (the one I'm about to release for 0.5.21,
which differs from egcs' versions a bit, I'm sure) *does*
include <stdlib.h> in its gcc/f/proj.h file, which is the
"central" file "every" front-end source file includes first.
(And I've changed it to #include <config.j> before anything
else -- config.j normally just does #include "config.h" from
gcc.)

I'd look into making g77 more compliant to various standards
right away, except I'm still working on a gcc-2.7.2.2 base,
where things like HAVE_STDLIB_H and such don't really exist.
Just hoping the few things I *am* doing don't make 0.5.21
worse than 0.5.20 for anyone; *that* would be embarrassing!

In another few weeks, I hope to be able to start making time
to work on egcs, especially the g77 side of it, etc. etc.

        tq vm, (burley)

Re: maintainer mode [was: Re: Building of generated parser files]

[Gary V Vaughan]

Surely, one could write a relatively bombproof checksum utility with a
few lines of shell (or sed), which the GNU standards allow us to assume
will be present in the build environment...  Just the choice of
algorithm really; how about SUM_OF_NON_WS_ASCII_ALNUM_CHARS modulo
MAX_INT?

Ian Lance Taylor wrote:
> 
>    Date: 27 Aug 1997 14:08:27 +0200
>    From: Samuel Tardieu <sam@inf.enst.fr>
> 
>    >>>>> "Ian" == Ian Lance Taylor <ian@cygnus.com> writes:
> 
>    Ian> I guess the main difficulty I see is the lack of a standard
>    Ian> checksum program.  Everything else seems workable.
> 
>    Why not including a small one in the distribution, to be built soon enough?
> 
> That would lead us into a whole new set of problems, involving finding
> a working compiler for the build system which can generate programs we
> can execute.  Remember, we might be building with a cross compiler.
> These problems are probably solvable, but at some point the solution
> becomes worse than the disease.
> 
> Ian

Re: maintainer mode [was: Re: Building of generated parser files]

[Kaveh R. Ghazi]

 >    Date: 27 Aug 1997 14:08:27 +0200
 >    From: Samuel Tardieu <sam@inf.enst.fr>
 >  
 >    >>>>> "Ian" == Ian Lance Taylor <ian@cygnus.com> writes:
 >  
 >    Ian> I guess the main difficulty I see is the lack of a standard
 >    Ian> checksum program.  Everything else seems workable.
 >  
 >    Why not including a small one in the distribution, to be built soon enough?
 >  
 > That would lead us into a whole new set of problems, involving finding
 > a working compiler for the build system which can generate programs we
 > can execute.  Remember, we might be building with a cross compiler.
 > These problems are probably solvable, but at some point the solution
 > becomes worse than the disease.
 >  
 > Ian


	How about supplying both sysv and bsd checksums and allow the
comparison test to pass if either value matches that generated by the
system's "sum" program?

		--Kaveh
--
Kaveh R. Ghazi				Project Manager
ghazi@caip.rutgers.edu			ICon CMT Corp.

Re: maintainer mode [was: Re: Building of generated parser files]

[Ian Lance Taylor]

   Date: 27 Aug 1997 14:08:27 +0200
   From: Samuel Tardieu <sam@inf.enst.fr>

   >>>>> "Ian" == Ian Lance Taylor <ian@cygnus.com> writes:

   Ian> I guess the main difficulty I see is the lack of a standard
   Ian> checksum program.  Everything else seems workable.

   Why not including a small one in the distribution, to be built soon enough?

That would lead us into a whole new set of problems, involving finding
a working compiler for the build system which can generate programs we
can execute.  Remember, we might be building with a cross compiler.
These problems are probably solvable, but at some point the solution
becomes worse than the disease.

Ian

Re: Some Linux patches

[Richard Henderson]

> 	* config/alpha/linux.h (DEFAULT_VTABLE_THUNKS): New. Defined
> 	as 1.

This should not be unconditional.  It is wrong for alpha-linux-ecoff
(not that I think anyone will notice) and glibc1.


r~

Re: maintainer mode [was: Re: Building of generated parser files]

[Samuel Tardieu]

>>>>> "Ian" == Ian Lance Taylor <ian@cygnus.com> writes:

Ian> I guess the main difficulty I see is the lack of a standard
Ian> checksum program.  Everything else seems workable.

Why not including a small one in the distribution, to be built soon enough?

  Sam

  Sam
-- 
Samuel Tardieu -- sam@inf.enst.fr

Re: maintainer mode [was: Re: Building of generated parser files]

[Richard Stallman]

    I don't know what to do about the checksum program, though.  GNU
    systems will normally have md5sum, but unfortunately there isn't a
    standard sum program on other systems, since the BSD and System V
    checksum algorithms differ.

That seems like a pretty bad flaw in my idea.  Oh well.

Re: maintainer mode [was: Re: Building of generated parser files]

[Kaveh R. Ghazi]

 > I don't know what to do about the checksum program, though.  GNU
 > systems will normally have md5sum, but unfortunately there isn't a
 > standard sum program on other systems, since the BSD and System V
 > checksum algorithms differ.
 >  
 > Ian

	You could provide both BSD and SYSV sums and if the computed sum
matches either of these, then assume everything is okay.

	There is a slight chance of mismatch (when a corrupted file's
computed SYSV sum matches the supplied BSD sum or vice versa) but for
this purpose it should be okay. 

		--Kaveh
--
Kaveh R. Ghazi				Project Manager
ghazi@caip.rutgers.edu			ICon CMT Corp.

Re: Test run and a question

[Joe Buck]

> egcs/gcc/cp/NEWS
> 
> comments are welcome.

Great document.  I suggest adding notes about which template features are
still not supported (template class member functions and templates as
template arguments), and clarifying that c++ and g++ link libstdc++.a
so folks don't panic when they see libg++ is no longer linked in.

Joe

Re: maintainer mode [was: Re: Building of generated parser files]

[Alexandre Oliva]

Richard Stallman writes:

> When a distribution contains non-source files, the makefile rules
> for these targets could be designed to check checksums of them and
> the sources they were made from.

I was thinking the same.  Autoconf could produce the checksums itself,
and insert them in the generated file.  I had thought of somethink
such as:

configure.in should contain a line such as:

# Autoconf dependencies checksums: ;

the generated configure script would then contain:

# Autoconf dependencies checksums: configure.in:<checksum> ;

config.h.in could contain:
/* Autoconf dependencies checksums: acconfig.h:<checksum> aclocal.m4:<checksum> ; */
that would be replaced with:

/* Autoconf dependencies checksums: config.h:<checksum> ; */

It would be quite easy to check those dependencies on Makefiles.  In
fact, this check could be easily performed by the `missing' script, so
that it would only touch the file if the checksums matched.

I particularly disliked the `Autoconf dependencies checksums' string,
but I could not thing of anything better.  Maybe a RCS-like
$Checksums$ string would do it...

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

Re: maintainer mode [was: Re: Building of generated parser files]

[Ian Lance Taylor]

   Date: Tue, 26 Aug 1997 15:15:02 -0400
   From: Richard Stallman <rms@gnu.ai.mit.edu>

   Here is another idea.  When a distribution contains non-source files,
   the makefile rules for these targets could be designed to check
   checksums of them and the sources they were made from.  If these show
   that a certain target file and the relevant sources are all unchanged
   from the distribution versions, the rule would either do nothing, or
   just touch the output file.

I guess the main difficulty I see is the lack of a standard checksum
program.  Everything else seems workable.

$(srcdir)/configure.in.sum: $(srcdir)/configure.in
	$(SUM) $(srcdir)/configure.in > $(srcdir)/configure.in.sum

$(srcdir)/configure: $(srcdir)/configure.in $(srcdir)/configure.in.sum
	$(SUM) $(srcdir)/configure.in > test.sum
	if [ cmp test.sum $(srcdir)/configure.in.sum >/dev/null ]; then \
	  touch $(srcdir)/configure.in; \
	else \
	  cd $(srcdir) && autoconf; \
	fi

This would have to be modified a bit to allow for read-only source
distributions.

I don't know what to do about the checksum program, though.  GNU
systems will normally have md5sum, but unfortunately there isn't a
standard sum program on other systems, since the BSD and System V
checksum algorithms differ.

Ian

Re: maintainer mode [was: Re: Building of generated parser files]

[Fred Fish]

> Here is another idea.  When a distribution contains non-source files,
> the makefile rules for these targets could be designed to check
> checksums of them and the sources they were made from.  If these show
> that a certain target file and the relevant sources are all unchanged
> from the distribution versions, the rule would either do nothing, or
> just touch the output file.

There would need to be a way to force the target to be remade if, for
example, I fixed a bug in the tool that generated the target from it's
source files and wanted to regenerate the target with the new tool.
Same goes for installed an updated tool, like a new release of bison
for example.

-Fred

Re: maintainer mode [was: Re: Building of generated parser files]

[Ian Lance Taylor]

   From: Frangois Pinard <pinard@iro.umontreal.ca>
   Date: 26 Aug 1997 11:29:45 -0400

   This yields Makefiles to be incorrect, as necessary dependencies are being
   lost.  If people do not have autoconf or automake installed, and Makefiles
   were correct, Makefiles should at least loudly warn about the fact autoconf
   and automake are needed, for when they are needed.  This is the purpose
   of the `missing' script, which Automake now distributes and prefers.

I disagree.  Timestamps often get messed up as programs travel around
the net.  When there are default rules for files like configure and
Makefile.in, this can lead make to try to rebuild them.  When naive
users see the loud warnings from the missing program, they will
believe that something has gone wrong, and will report it as a bug.
In fact, though, nothing has gone wrong.

Even worse, if the users happen to have an old version of autoconf or
automake installed, then configure or Makefile.in will be rebuilt, but
may be rebuilt incorrectly.  This will be reported as a more subtle
bug.

I also don't want to get into a debate about this.  In fact, I don't
see any way to resolve such a debate.  Either choice has problems.  I
happen to weigh the problems differently, which leads me to a
different preference.

Ian

Re: Some Haifa scheduler bugs

[Bernd Schmidt]

> 
> So, how about this:
> 
> static rtx
> move_insn (insn, last)
>      rtx insn, last;
> {
>   while (SCHED_GROUP_P (insn))
>     {
>       rtx prev = PREV_INSN (insn);
>       move_insn1 (insn, last);
>       reemit_notes (insn, insn);
>       insn = prev;
>     }
> 
>   move_insn1 (insn, last);
>   return reemit_notes (insn, insn);
> }

I think you won't get the right return value. You want to return the
last insn in a SCHED_GROUP or a note that was placed after it.
I had my reasons to use two loops ;)

The whole affair with SCHED_GROUP_P is extremely messy. How about using
extra data structures that describe which insns to schedule together,
which notes to put before them, and the dependencies between them,
instead of trying to encode it all in the RTL with the confusion that
results?
If you don't want that, changing the meaning of SCHED_GROUP_P for the
Haifa scheduler so that it is set if the _following_ insn must be
scheduled together with an insn might make the code clearer. I think it
would fit in better with the fact that Haifa schedules forward. I didn't
try it, though; maybe there are problems with that approach, too.

Bernd

maintainer mode [was: Re: Building of generated parser files]

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]

Hi, people.  Please, please read me carefully.  I do not want to make
a long crusade nor to get involved into a debate, so I tried to say
everything important at once, here, in one single blow.  Keep happy!

Ian Lance Taylor <ian@cygnus.com> summarises what "maintainer mode" is:
| --enable-maintainer-mode is currently being used by automake.  [...]
| The intention is that people who configure normally, without
| --enable-maintainer-mode, will not have to worry about the timestamp
| of their configure.in vs. their configure, and so forth.  This matters
| because most people will not have autoconf or automake installed.

This yields Makefiles to be incorrect, as necessary dependencies are being
lost.  If people do not have autoconf or automake installed, and Makefiles
were correct, Makefiles should at least loudly warn about the fact autoconf
and automake are needed, for when they are needed.  This is the purpose
of the `missing' script, which Automake now distributes and prefers.

It is very wrong, in my opinion, that "maintainer mode" in GNU opens
the door to buggy Makefiles, and to undependable or unreliable builds.
GNU should just distribute plain correct Makefiles.  If they have to be
made incorrect, that should be under explicit request, and never be the
default state in a distribution.  I think that GNU should not even favour
an option to turn GNU Makefiles into incorrect Makefiles.

Richard Stallman <rms@gnu.ai.mit.edu> writes:
| [...] but I am not sure the change is actually an improvement.

The whole concept of "maintainer mode" is very far from being an
improvement.  It is an aberration.  It is an historical error in GNU,
which should be corrected and forgotten as fast as possible, really.

Jim Meyering <meyering@eng.ascend.com> writes:
| FYI, the fileutils, sh-utils, and textutils have been providing
| --enable-maintainer-mode for over a year.  It seems to have had
| the desired effect.

And on the same thread, Niklas Hallqvist <niklas@petra.appli.se> writes:
> Personally, I like --enable-maintainer-mode, and I think we should go
> with it.

If people learn to like "maintainer mode", that is, buggy Makefiles, then
"maintainer mode" has a long term and very undesirable side effect, not
worth the temporary good it can bring.  The three *utils have been wrong
for over a year at purposely distributing incorrect Makefiles.  To be
wrong for a long while does not make something good, it only make it worse.

-- 
François Pinard                          mailto:pinard@iro.umontreal.ca
Support Programming Freedom, join our League!  Ask lpf@lpf.org for info