Hi Lucas, > > 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? 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 -- 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
