Return-Path: MIME-Version: 1.0 In-Reply-To: <1346428924.23377.12.camel@aeonflux> References: <1346332740-29319-1-git-send-email-anderson.lizardo@openbossa.org> <1346339333.23377.10.camel@aeonflux> <1346428924.23377.12.camel@aeonflux> From: Lucas De Marchi Date: Fri, 31 Aug 2012 13:11:39 -0300 Message-ID: Subject: Re: [PATCH BlueZ] build: Use AC_USE_SYSTEM_EXTENSIONS for POSIX/C extensions To: Marcel Holtmann Cc: Anderson Lizardo , linux-bluetooth@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 List-ID: On Fri, Aug 31, 2012 at 1:02 PM, Marcel Holtmann wrote: > Hi Lucas, > >> > On Thu, Aug 30, 2012 at 11:08 AM, Marcel Holtmann 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. seriously? before 2.60? It's already a pre-requisite in our configure.ac > > 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. If it helps to convince you: systemd, kmod, pulseaudio, libabc, and many others.... all of them use these macros. Lucas De Marchi