user supplied CFLAGS/LDFLAGS is not respected

[Qian Yun]

There is this gentoo bug: https://bugs.gentoo.org/728048

The CFLAGS/LDFLAGS flags are not propagated properly in Makefiles.

I think the attached patch fixes this.

Further more, shall we remove CCF and LDF? (Instead, we give
CFLAGS/LDFLAGS a default setting.)

- Qian

[Waldek Hebisch]

On Sun, Sep 01, 2024 at 10:32:39AM +0800, Qian Yun wrote:
> There is this gentoo bug: https://bugs.gentoo.org/728048
>
> The CFLAGS/LDFLAGS flags are not propagated properly in Makefiles.
>
> I think the attached patch fixes this.

It looks OK assuming that we want behaviour that you implemented.
However, it is not 100% clear what CFLAGS/LDFLAGS should do.
For example, in principle for correct configuration we should
use the same flags both during configure and build. So arguably
CFLAGS should be propagated from configure to makefiles.

> Further more, shall we remove CCF and LDF? (Instead, we give
> CFLAGS/LDFLAGS a default setting.)

AFAICS some setting in CCF may be needed for correct build. So
it is nor clear if we can remove CCF and LDF. Certainly
CFLAGS/LDFLAGS can not serve as a replacement.

--
Waldek Hebisch

[Qian Yun]

On 9/2/24 8:13 AM, Waldek Hebisch wrote:
> On Sun, Sep 01, 2024 at 10:32:39AM +0800, Qian Yun wrote:
>> There is this gentoo bug: https://bugs.gentoo.org/728048
>>
>> The CFLAGS/LDFLAGS flags are not propagated properly in Makefiles.
>>
>> I think the attached patch fixes this.
>
> It looks OK assuming that we want behaviour that you implemented.
> However, it is not 100% clear what CFLAGS/LDFLAGS should do.
> For example, in principle for correct configuration we should
> use the same flags both during configure and build. So arguably
> CFLAGS should be propagated from configure to makefiles.
>

If you export CFLAGS in environment variables, it is already picked
up by configure automatically.

- Qian

./configure --help

Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
CPP C preprocessor
XMKMF Path to xmkmf, Makefile generator for X Window System

Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.

[Waldek Hebisch]

On Mon, Sep 02, 2024 at 07:15:12PM +0800, Qian Yun wrote:
>
>
> On 9/2/24 8:13 AM, Waldek Hebisch wrote:
> > On Sun, Sep 01, 2024 at 10:32:39AM +0800, Qian Yun wrote:
> > > There is this gentoo bug: https://bugs.gentoo.org/728048
> > >
> > > The CFLAGS/LDFLAGS flags are not propagated properly in Makefiles.
> > >
> > > I think the attached patch fixes this.
> >
> > It looks OK assuming that we want behaviour that you implemented.
> > However, it is not 100% clear what CFLAGS/LDFLAGS should do.
> > For example, in principle for correct configuration we should
> > use the same flags both during configure and build. So arguably
> > CFLAGS should be propagated from configure to makefiles.
> >
>
> If you export CFLAGS in environment variables, it is already picked
> up by configure automatically.

I mean that some folks expect CFLAGS given to configure to propagate
to Makefiles. For that we would need

AC_SUBST(CFLAGS)

in 'configure.ac' and something like

CFLAGS=@CFLAGS@

in relevant Makefiles (or better 'var_def.mk').

--
Waldek Hebisch

[Qian Yun]

On 9/2/24 7:56 PM, Waldek Hebisch wrote:
> On Mon, Sep 02, 2024 at 07:15:12PM +0800, Qian Yun wrote:
>>
>>
>> On 9/2/24 8:13 AM, Waldek Hebisch wrote:
>>> On Sun, Sep 01, 2024 at 10:32:39AM +0800, Qian Yun wrote:
>>>> There is this gentoo bug: https://bugs.gentoo.org/728048
>>>>
>>>> The CFLAGS/LDFLAGS flags are not propagated properly in Makefiles.
>>>>
>>>> I think the attached patch fixes this.
>>>
>>> It looks OK assuming that we want behaviour that you implemented.
>>> However, it is not 100% clear what CFLAGS/LDFLAGS should do.
>>> For example, in principle for correct configuration we should
>>> use the same flags both during configure and build. So arguably
>>> CFLAGS should be propagated from configure to makefiles.
>>>
>>
>> If you export CFLAGS in environment variables, it is already picked
>> up by configure automatically.
>
> I mean that some folks expect CFLAGS given to configure to propagate
> to Makefiles. For that we would need
>
> AC_SUBST(CFLAGS)

https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Preset-Output-Variables.html

I think CFLAGS and LDFLAGS are predefined so AC_SUBST is not needed.

> in 'configure.ac' and something like
>
> CFLAGS=@CFLAGS@
>
> in relevant Makefiles (or better 'var_def.mk').
>

CFLAGS is already in 'var_def.mk', so only LDFLAGS is missing there.

- Qian

[Waldek Hebisch]

Yes, it looks so.

--
Waldek Hebisch

[Qian Yun]

On 9/4/24 3:55 AM, Waldek Hebisch wrote:
>>>
>>
>> CFLAGS is already in 'var_def.mk', so only LDFLAGS is missing there.
>
> Yes, it looks so.
>

Shall I proceed with the patch and adding LDFLAGS to 'var_def.mk'?

- Qian

[Waldek Hebisch]

Yes.

--
Waldek Hebisch

[Qian Yun]

Committed as
https://github.com/fricas/fricas/commit/cad5dae9ff32cdbbb3d5187ed4ab4c716c16d2d6

CCing gentoo maintainer:

together with
QA_FLAGS_IGNORED="usr/lib.*/fricas/target/.*/bin/FRICASsys"
https://bugs.gentoo.org/728048 should be fixed.

- Qian

[Waldek Hebisch]

On Sat, Sep 07, 2024 at 08:54:11AM +0800, Qian Yun wrote:
> Committed as https://github.com/fricas/fricas/commit/cad5dae9ff32cdbbb3d5187ed4ab4c716c16d2d6
>
> CCing gentoo maintainer:
>
> together with
> QA_FLAGS_IGNORED="usr/lib.*/fricas/target/.*/bin/FRICASsys"
> https://bugs.gentoo.org/728048 should be fixed.

Well, maybe they may mark it now as resolved, but it is not clear
if they will get desired effect for 'FRICASsys'. Namely,
only small loader part is visible to C-oriented tools. Bulk
of the code (that is all code written in Lisp) is just a big
blob to C-oriented tools. Graphics, hyperdoc, 'sman', 'clef'
are normal C programs, so for them problem should be resolved.
But 'FRICASsys' is different. I remember that one distribution
(do not remember which one) wanted to install debug info for
'FRICASsys'. But they indexed info on executable content
and from point of view of tools executable part of 'FRICASsys'
was the same as of 'sbcl' and tools did not allow duplicate
binaries.

--
Waldek Hebisch

[Qian Yun]

Yes, 'FRICASsys' is not affected by CFLAGS/LDFLAGS.

This variable in gentoo's ebuild
QA_FLAGS_IGNORED="usr/lib.*/fricas/target/.*/bin/FRICASsys"
will tell gentoo's QA system to ignore the checks for "FRICASsys".

- Qian