Re: [PATCH] More accessible usage of custom flags

[Nick Andrew]

On Sun, Feb 24, 2008 at 04:36:24AM -0500, Nicholas Marquez wrote:
> Yes, I would like to expand them.  If possibly, I'd like to take out
> the individual config options for gcc flags and integrate them into
> the help description.  I feel that the redundancy would not only be
> ugly, but possibly confusing.

If you allow CUSTOM_CFLAGS and friends (as an open-ended set of flags for
the compiler) then yes, having config options like CC_OPTIMIZE_FOR_SIZE
is redundant and should be removed.

Alternately, don't have a CUSTOM_CFLAGS and expand on the set of config
options which set individual compiler flags.  They could be in their
own menu, a bunch of checkboxes to tweak GCC's various optimisation
algorithms and/or warnings. That's certainly going to be friendlier
for the not-very-experienced kernel builder, if less flexible than
CUSTOM_CFLAGS.

> >  I'm hoping we don't need any stern warnings in the kernel configuration.
> >  Although I expect configuring bogus gcc flags is going to break the
> >  build far worse than selecting bad options otherwise. If the user
> >  makes a mistake in CUSTOM_CFLAGS is the build going to fail with
> >  a message "error in CUSTOM_CFLAGS" or is it going to spew out pages
> >  of gcc error messages?  It is nice if error messages can point back
> >  to the source of the error, so the user doesn't have to look through
> >  the entire kernel configuration for what they did wrong.
> 
> I hadn't thought of that.  It would certainly be more useful than a
> stern warning.  ^^;  Have you any ideas on how to implement such a
> thing?  I would imagine a configure-script-like test on the flags to
> make sure that gcc could take them correctly would be in order.  Then
> one could also capture any warnings or errors that gcc outputs (such
> as redundant flags, improper invocation, etc.), fail the build, and
> output the messages.  As far as capturing dangerous flags for the
> kernel (such as -ffast-math or -fmerge-all-constants), there could be
> a blacklist... but that would depend on the gcc version used... :/

I think that's a very interesting idea. Yes, you can test the flags by
compiling and linking a simple program. If it fails, your flags are
bad. You can stop the build right there and say "fix your flags".

The build could also capture the GCC warning/error output and
post-process it. Certain types of warnings might be suppressed,
or cause the build to fail (based on selected config options). My
kernel builds always show a handful of "may be used uninitialised" or
similar ... I just assume that those warnings are harmless. It is best
of course that these warnings don't occur at all, and I expect kernel
developers to fix them when they get a chance.  The idea in this
paragraph would be desirable to me, independent of how the CFLAGS are
specified.


> >  > Something else that could be included is a link to the manual for the
> >  > (currently used) gcc's command flags
> >  > (http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/index.html#toc_Invoking-GCC)
> >  > or at least to the online docs, considering that specifying one
> >  > specific gcc version's manual would yield various issues.
> >
> >  "info gcc" will give all that information in far more detail than I
> >  have time to read.
> 
> I believe you misunderstand.  I mean to include the link in the help
> message.  Like how the links to the appropriate sites for device
> drivers are included in their help messages.

No, I think I understood correctly. If you tell the user to go to that
long URL then you run the risk of pointing to the documentation for a
different version of GCC. On the other hand, if you tell them to type
"info gcc" then they will see the documentation for the version of GCC
which they have installed. And it's also a lot friendlier to write:
"Type 'info gcc' to see a full list of the compiler options".

> >  > I feel that perhaps it is a bit silly to put in such description, as
> >  > one using the flags should only do so in knowing specifically which
> >  > ones they wish to use and why ahead of time.  However, it cannot hurt
> >  > to put in more help documentation, so it's a fine suggestion.
> >
> >  Well, it can't be both silly and a fine suggestion. Does it dumb down
> >  the kernel configuration process too much?
> 
> No, I feel that both adjectives are perfectly reconcilable, at least
> in this case.  Again, more documentation couldn't hurt.  "Dumbing
> down" kernel configuration may be less aesthetically pleasing to
> purists, but that is a tiny price to pay for usability and a widening
> of kernel builders.

I'm looking to find a balance among the competing objectives. Time
will tell with any improvements. I'm also hoping for an aesthetically
pleasing config menu -- perhaps someone else can take on the challenge of
restructuring it to improve the ordering, structure and names of options.

> PS to Nick:  Sorry for the double-send. Didn't CC lkml;  a forward
> would be ugly.

No prob.

Nick.
-- 
PGP Key ID = 0x418487E7                      http://www.nick-andrew.net/
PGP Key fingerprint = B3ED 6894 8E49 1770 C24A  67E3 6266 6EB9 4184 87E7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/