All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.