Hi, Many thanks for your response. Nick Bowler (2023/09/11 13:56 -0400): > On 2023-09-11, Sébastien Hinderer <Sebastien.Hinderer@xxxxxxxxxxxx> wrote: > > I am writing with a quesiton about the AC_SYS_LARGEFILE macro. > > > > It would be great to be able to use it but according to its > > documentation, the macro adds its flags to the CC output variable, which > > is not convenient in my context because we have dedicated variables not > > only for C flags but also for C preprocessor flags. > > Autoconf is designed to facilitate build systems that comply with the > GNU coding standards. I don't think the one we are using doesn't comply with GNU coding standards, actually. However it seems my wording implied it. Sorry about that and the confusion it created. > CFLAGS and CPPFLAGS cannot be used for large-file support because > these flags are required for proper compilation, and the standards > say such flags don't go into CFLAGS or CPPFLAGS. We don't put our flags there, actuallly. For each public variable we have a private counterpart. So for CFLAGS, say, we also have MY_CFLAGS whose value is computed at configure time and substituted and then all our build rules use both $(MY_CFLAGS) and $(CFLAGS) to let the user the last word but without accidentally overrinding flags the build system would have defined. > This is because > the user is supposed to be able to override these variables. Indeed. > For > example: > > % ./configure > % make CFLAGS=-g3 > > would almost certainly break horribly if configure put any large-file > support options into CFLAGS. > > Looking at the code, CC is modified only if the -n32 option is needed > to enable large-file support. The comments suggest this is required > on IRIX. If large-file support can be enabled by preprocessor macros > (which I imagine is the case on all current systems), AC_DEFINE is > used. OK thanks for having looked into it! What I am considering is to use a local copy of the macro but tailored to fit with our build system conventions. I am expecting this macro not to change that often, actually, so I am guessing that a copy wouln't be worth than the hard-coded stuff we currently have. Put otherwise, it wouldhave the merit of isolating the hard-coded stuff and to make it easier to update,shouldthe macro change. > It has been this way since the macro was originally added to Autoconf. > I can only speculate as to why the original author used CC, but the > reason is probably so that you can just take an existing package and > just add AC_SYS_LARGEFILE with no other modifications and it will > almost certainly work without any major problems. Ah, this indeed makes a lot of sense. Many thanks for sharing this insight. > Anything else would likely fail to comply with the standards or would > require package maintainers to edit their makefiles to ensure some new > variable is included on every compiler command line. > > If they miss one, then their program would work perfectly almost > everywhere but fail when building on IRIX (probably a more serious > concern when this macro was added back in 2000 than it is today). Yes, I'm following you. > Furthermore, in the real world, package authors are notoriously bad at > ensuring CFLAGS is properly passed to every single C compiler > invocation. I od a lot of effort in this direction for the build system I am working on. > But people are usually much better at using CC consistently. Indeed. Just that in our project I think we kind of assume $(CC) is the name of a program, although I don't think we actually rely on this assumption anywhere. > > Thus, what I'd ideally need is a version of the macro where I can > > somehow specify what to do with both large-file related CFLAGS and > > CPPFLAGS. > > If you really don't want configure modifying CC on IRIX, while still > complying with the GNU coding standards, then you can do something like > this instead (untested): > > save_CC=$CC > AC_SYS_LARGEFILE > AS_IF([test x"$CC" != x"$save_CC"], > [dnl The undocumented cache variable ac_cv_sys_largefile_CC > dnl here exists in every version of Autoconf with AC_SYS_LARGEFILE; > you could also dnl pick apart $CC to find out what flags were added. > AC_SUBST([$LARGEFILE_FLAGS], [$ac_cv_sys_largefile_CC]) > CC=$save_CC]) > > Then, modify your Makefiles to ensure $(LARGEFILE_FLAGS) is included > on every compiler command line. > > Hope that helps, It does yes, thanks. Quite a lot actually. I'll definitely take the snippet above as a source of inspiration. Best wishes, Sébastien.