Re: AC_SYS_LARGEFILE

[Sébastien Hinderer]

Hi,

Many thanks for your response.

Nick Bowler (2023/09/11 13:56 -0400):
> On 2023-09-11, Sébastien Hinderer <Sebastien.Hinderer@ens-lyon.org> 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.