Hi Marcel, On Thu, Aug 30, 2012 at 12:26 PM, Anderson Lizardo <anderson.lizardo@xxxxxxxxxxxxx> wrote: > Hi Marcel, > > On Thu, Aug 30, 2012 at 11:08 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> 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? 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 Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
