Re: [Pio-temporary] Turn on compiler warnings

[Bas W. <sh...@fm...>]

On Sat, Sep 17, 2005 at 03:05:25PM +0200, Roland Clobus wrote:
> Hello all,
>=20
> I've decided to move the discussion from the tracker to the mailing=20
> list. Previous discussion in the tracker (Patches item #1293678):

Good idea.

> Ever since rules.make was introduced, it was a hack because it would=20
> allow us to do things that we could not do with the autoconf tools.
> I would like to see that file removed eventually.

I agree with that.  However, recently I noticed that automake supports
non-recursive Makefiles as well (that is, one Makefile in the toplevel
directory which has all the rules and doesn't call make for subdirectories).

There are several reasons that this is a good thing.  See
http://www.gnu.org/software/automake/manual/html_node/Alternative.html
and the article linked from there.

Now if we would go for this approach, we would of course no longer need
rules.make.

> For now, the discussion focusses on the debug_includes part.
>=20
> Bas wrote a patch that would merge the warnings settings and the debug=20
> settings to the variable extra_includes, by modifying rules.make

Right.  While I agree that it should eventually be removed somehow (I'd pre=
fer
generating one Makefile from a Makefile.am which includes Makefile.am's from
other subdirectories to keep things readable), this patch does not attempt =
to
make a start with that.

> I prefer to use the configure.ac way because that will allow fine=20
> grained control over the arguments to gcc. It will also disable the=20
> commandline arguments that enable the compiler warnings when another=20
> compiler than gcc is found.

I assume can also be done with only a test in configure.ac, and the
implementation in Makefile.am.

> Bas, you wrote:
> <quote>
> I think the strings
> which end up in the final Makefile should be defined in
> Makefile.am (or in /usr/share/aclocal/*.m4 as a variable
> definition to be referenced in Makefile.am).
> </quote>
>=20
> I'm not sure what do you mean by that.

I see configure.ac as a place to test for things and to copy things into the
Makefile, not to actually generate content (for the Makefile).  That content
should be in Makefile.in, substituted with flags definitions (which are in
/usr/share/aclocal).

> I see configure.ac as a customized version of /usr/share/aclocal/*.m4.=20

I don't, I see it as the manager to use the information in there and merge =
it
with the local things which are in Makefile.am.

> If the text to turn the warnings on is too long, I could separate it=20
> to a *.m4 file, but the effect would be the same.

The effect is the same when we do it via rules.make as well. ;-)

However, if you prefer to see this as a flag, and you want to define it in =
an
debug.m4 file which is used in configure.ac and then referenced in Makefile=
=2Eam
to be used, I don't mind.  An other option is to add them to the compiler
definition.  That is something which should be done in configure.ac.  But in
any case, if using a separate .m4 file, it should IMO only define flags in
there, they should be used elsewhere.

I hope this explains better how I see it.

Thanks,
Bas

--=20
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html