Re: Per-source CFLAGS

From: Bruce Evans (bde_at_zeta.org.au)
Date: 06/22/03

  • Next message: Ruslan Ermilov: "Re: Per-source CFLAGS" 
    Date: Sun, 22 Jun 2003 18:23:20 +1000 (EST)
To: David Schultz <dschultz@OCF.Berkeley.EDU>

    On Sat, 21 Jun 2003, David Schultz wrote:

    > On Sun, Jun 22, 2003, Bruce Evans wrote:
    > > For this, you really want per-file WARNS, since among other reasons
    > > compiler-dependent flags shouldn't be put in individual Makefiles.
    > > ...
    > > Do you need to turn off all warnings or just ones for non-broken
    > > precedence and a few other non-broken things? gcc doesn't give
    >
    > In this case, we really do want to ignore all the warnings. This
    > is vendor code, written in a style that makes it easiest for the
    > author to maintain.

    But not necessarily easiest for us to maintain. We enable some
    warnings for lots of things under contrib although most things
    under contrib are not FreeBSD-warning clean. I realize that gdtoa
    is special since it is compiled as part of libc.

    > It so happens that -w is a de facto (if not
    > de jura) standard; it is supported by the GNU, Intel, and Sun C
    > compilers at least.

    It's not de-jure in POSIX (c99).

    > > > # SINGLE SUFFIX RULES
    > > > .c:
    > > > - ${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${.IMPSRC}
    > > > + ${CC} ${CFLAGS} ${CFLAGS_${.IMPSRC}} ${LDFLAGS} \
    > > > + -o ${.TARGET} ${.IMPSRC}
    > > > ...
    > >
    > > Some rules are specified by POSIX, so they can't be changed. I don't
    > > see how ${CFLAGS} can be per-file directly, so the POSIX spec seems to
    > > be actively opposed to per-file CFLAGS.
    >
    > ??? You mean we can't add a variable that will normally expand to
    > nil? This seems like a compatible change, unless you're worried
    > about someone's makefile breaking because they defined
    > CFLAGS_foo.c to mean something else.

    >From POSIX.1-200x-draft7.txt:

    % 23836 Default Rules
    % 23837 The default rules for make shall achieve results that are the same as if the following were used.
    % ...
    % 23864 SINGLE SUFFIX RULES
    % 23865 .c:
    % 23866 $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $<

    This leaves little scope for modifying the default rules.

    Bruce
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Ruslan Ermilov: "Re: Per-source CFLAGS"

    Relevant Pages

    • Re: does VS C++ 2005 actually work????
      ... But I've also dealt with these tons of new warnings. ... Microsoft gets a lot of ... Early versions of C compilers did not warn when unprototyped functions were ... I personally found intellisense failing far more often ...
      (microsoft.public.vc.mfc)
    • Re: Is it standard and practical to use long long types?
      ... >> Compilers are free to emit completely bogus warnings at any time. ... error messages are issued for syntax ...
      (comp.lang.c)
    • Re: [Lit.] Buffer overruns
      ... >>all errors and warnings enabled, ... > But then I'll switch compilers, and find a whole new bunch of whimsical ... > you just have to roll with the diagnostics, ... conditionals on the sizes of built-in types often generate warnings of ...
      (sci.crypt)
    • Re: Avoiding "unused dummy argument" warnings.
      ... argument" warnings from compilers in this case? ... I know it isn't a bug in terms of standard conformance. ... standard doesn't prohibit compilers from giving all kinds of silly ... (the gfortran crew), I won't bitch.... ...
      (comp.lang.fortran)
    • Re: Type-casting void pointers?
      ... There are some lousy compilers out there. ... delivering code with hundreds of warnings is not good for business). ... The cast, where it is obvious, can also be used as documentation: ...
      (comp.lang.c)