On Tue, Sep 17, 2002 at 02:00:27PM -0500, Eric Gillespie wrote:
> Dominik Vogt <fvwm-workers@fvwm.org> writes:
>
> > Yes, there is a very good reason: configure chokes on the
> > -Werror flag and produces more or less random test results.
> > This can be hell to debug. Maybe I can find a way to enable
> > the original CFLAGS again before they are placed in the
> > Makefiles.
>
> That is not generally sufficient, nor is setting the variables on
> the make command line. There is a reason for the standard
> behavior. If you have libraries installed outside the standard
> search path (/usr), you need to set CPPFLAGS and LDFLAGS before
> running configure. The most famous examples are /usr/X11R6 and
> /usr/local (yes, i know most (all?) GNU/Linux distributions put
> those on the standard search path, but that's just lunacy), but
> there are also things like /opt and /usr/pkg (where NetBSD
> packages are installed).
Okay, but what about CFLAGS? I don't care much about the CPPFLAGS
or LDFLAGS. And by the way, the paths of all libraries that fvwm
uses can be set with configure options.
> And no, it isn't generally sufficient for the configure script to
> set the appropriate options itself. That is necessary for the
> standard options (-L and -I), but not sufficient because
> sometimes platform- or site-specific settings are needed. For
> example, on NetBSD we always set an rpath with -Wl,-R, but on
> Darwin the linker will explode since it has no -R option.
> Configure scripts would be a mess if they had to handle this sort
> of thing.
>
> I say "generally" because, in my experience, it is not necessary
> to set these variables with fvwm. I think it's picking up
> /usr/{X11R6,pkg}/{include,pkg} from the gtk-config script. So
> the above paragraph may not apply to Fvwm (someone not using the
> Gtk stuff will have to comment), but it's good to keep in mind
> anyway. And it may be worth sticking with the standard behavior
> so as not to violate the principle of least surprise, if for no
> other reason.
> As for the -Werror example, that is just user error. There are
> things you need to put into CPPFLAGS (defines and includes), and
> there are things you can put in there that will break (code
> generation or scanning flags).
No, it isn't necessarily a user error. Sometimes, when one of the
autoconf/automake files has changed, an I type
$ make CFLAGS="-Wall -Werror -O2 -g"
configure is rerun automatically with the CFLAGS I passed to make.
When configure is not run, these options are fine. It's tedious
to keep that in mind. Last time I wasted half an hour hunting
bugs that were not there just because configure detected a
"non-ANSI" C compiler and did funny things in config.h.
Of course I can just strip the -Werror from the CFLAGS, but
non-gcc users won't profit then.
How about this: write a small test program that issues lots of
warnings with -Wall and AC_TRY_COMPILE it. When that fails,
configure bugs out with an error message.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
