On Sun, Feb 24, 2008 at 7:50 AM, Nick Andrew <nick@nick-andrew.net> wrote:
quoted text
> 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.

The problem with this is that it is very static.  As you are well
aware, options differ between gcc versions.  Some options also differ
in result depending on the gcc version; for example, -ftree-vectorize
in gcc 3.x versus gcc 4.x.  I believe that it would be cleaner to have
the custom flag menu and suggest some flags for specific uses, such as
-Os,  in the help description. It might look something like:

help
         You can use this to easily set custom gcc CFLAGS to be used
         for the entire kernel build process (including modules).

         Examples include:
         ~"-Os" to optimize for size, i.e. for an embedded system or for
         more efficient cache usage
         ~"-s" to strip all symbol table and relocation information

         Other compiler flags can be used for increasing or reducing
         optimisation, enabling debugging, cross compilation
         and so on.  Please use "info gcc" or "man gcc" for more
         reference.

         If unsure, leave blank.

And for LDFLAGS, examples include:
          ~"-S" to strip all debugging symbols, which are usually unnecessary
          unless you intend to debug the kernel
          ~"-s" to strip all symbol information from the kernel

And for MAKEFLAGS, examples could include:
          ~"-j{n}" where n is the number of jobs you'd like to run for
          make.  This will make the kernel building process be greatly
          faster.  A good rule of thumb is for n to be 1 + the number of
          processor cores that are on the compiling machine.
          ~"-K" to attempt to continue compilation, even if errors are
          encountered, running until all other compilation paths (that
          do not depend on any that have errored) complete.

These are of course, just a few examples, but it serves to show the idea.

quoted text
>
>
>  > >  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.

Glad you agree. ;)
quoted text
>
>
>
>  > >  > 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.

Is anyone else out there reading these messages?  Cleaning and
"upgrading" the kernel's configuration and build systems is something
that could both use a lot of input and a lot of helping hands.  ;)  If
you've any patches for usability, aesthetics, optimization,
configuration or build robustness, etc., now would be the time to
share.
quoted text
>
>
>  > 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
>
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/