From: Marcel Holtmann <marcel@holtmann.org>
To: Lucas De Marchi <lucas.demarchi@profusion.mobi>
Cc: Anderson Lizardo <anderson.lizardo@openbossa.org>,
linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH BlueZ] build: Use AC_USE_SYSTEM_EXTENSIONS for POSIX/C extensions
Date: Fri, 31 Aug 2012 09:02:04 -0700 [thread overview]
Message-ID: <1346428924.23377.12.camel@aeonflux> (raw)
In-Reply-To: <CAMOw1v7bbYbhL59-imjzppztpC+e9+enTWx4nnWeVAT0zjW4Ag@mail.gmail.com>
Hi Lucas,
> > On Thu, Aug 30, 2012 at 11:08 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> >> Hi Anderson,
> >>
> >>> Using this macro in configure.ac enables certain extensions that BlueZ
> >>> currently depends on. The macro is recommended instead of defining
> >>> _GNU_SOURCE on each C file.
> >>
> >> what is the advantage of this. I am actually fine with using _GNU_SOURCE
> >> in the C files. It is according to the man pages.
> >
> > The only advantage I see is that we don't have to worry about
> > reviewing these defines as the symbols get incorporated in newer
> > standards. For instance, this patch was brought up because O_CLOEXEC
> > does not exist on POSIX.1-2001, but was incorporated POSIX.1-2008, so
> > for newer systems _GNU_SOURCE is not necessary for it anymore, but for
> > some (still maintained) distros it is.
> >
> > Sometimes we remove code that used these extensions, and simply forget
> > the _GNU_SOURCE there as well.
>
> And also forget to add it. Then 3 months later comes a patch to fix it
> by adding the definition.
>
> Using the autofoo macro we stop the build-fix patches for things like this.
>
>
> That is: it removes code, it's more future-proof and it has no
> downsides. So, what's the point of not using it?
unless that autoconf thing breaks and we don't get what we want. Or we
are dealing with an outdated autoconf.
I am against this. I rather get build fixes and have them recorded in
git compared to hoping that this magically fixes everything.
> Some months ago I sent a patch to also remove a lot of dumb "#include
> config.h". It has the same reasoning behind it: remove code and be
> more future-proof. It was for connman, but if you are interested I can
> send it to bluez/ofono/etc too -
> http://permalink.gmane.org/gmane.linux.network.connman/7310
Same thing. I believe that boilerplate is better being explicit than
magically having it done.
Regards
Marcel
next prev parent reply other threads:[~2012-08-31 16:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-30 13:19 [PATCH BlueZ] build: Use AC_USE_SYSTEM_EXTENSIONS for POSIX/C extensions Anderson Lizardo
2012-08-30 15:08 ` Marcel Holtmann
2012-08-30 15:26 ` Anderson Lizardo
2012-08-30 20:02 ` Lucas De Marchi
2012-08-31 16:02 ` Marcel Holtmann [this message]
2012-08-31 16:11 ` Lucas De Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1346428924.23377.12.camel@aeonflux \
--to=marcel@holtmann.org \
--cc=anderson.lizardo@openbossa.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=lucas.demarchi@profusion.mobi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox