mdocml [CVS_2015_11_07] Use of CPPFLAGS and LDFLAGS

mdocml [CVS_2015_11_07] Use of CPPFLAGS and LDFLAGS

[Peter Bray]

Greetings,

When configuring mdocml from CVS (2015-11-07 11:47AEST), I noticed
that 'configure' did not find sqlite, which on my system is not in
/usr/local or /usr.

Investigations showed that neither CPPFLAGS or LDFLAGS are used by the
'configure' script. Adding to 'configure.local' the following:

CC="${CC}"
CFLAGS="${CPPFLAGS} ${CFLAGS} ${LDFLAGS}" # No support for CPPFLAGS / 
LDFLAGS

Fixed the issue, and sqlite was found.

Investigating further, I found the 'Makefile' does use LDFLAGS, but
'configure' does not. And the project does not use CPPFLAGS at all.

My understanding (likely derived from GNU make(1), which I use
extensively), is that CPPFLAGS, LDFLAGS and LIBS are the standard
make(1) / environment variables to control the search paths and
additional required libraries. As in,

   CPPFLAGS: For -I<path>, -D<var>[=<value>] and -U<var>
   LDFLAGS:  For -L<path> and -R<path>
   LIBS:     For -l<library> (eg -lrt for nanosleep() on Solaris 10)

Question: Should 'configure' and 'Makefile' be using CPPFLAGS and
LDFLAGS by default? So that the person building the mdocml project
does not need to provide additional configuration for the build
process.

Regards,

Peter Bray
Sydney, Australia

PS: Happy to be pointed to references as to why these variables are
not used by some UNIX-like Operating Systems, if that is the case.

PPS: My own FLOSS build system has for 64-bit:

     % env | egrep 'FLAGS|LIBS'
     LDFLAGS=-L/pkgs/64-bit/lib/amd64 -L/pkgs/64-bit/lib
     CPPFLAGS=-I/pkgs/64-bit/include -I/pkgs/include

and for 32-bit:

     % env | egrep 'FLAGS|LIBS'
     LDFLAGS=-L/pkgs/32-bit/lib
     CPPFLAGS=-I/pkgs/32-bit/include -I/pkgs/include

--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

Re: mdocml [CVS_2015_11_07] Use of CPPFLAGS and LDFLAGS

[Ingo Schwarze]

Hi Peter,

Peter Bray wrote on Sat, Nov 07, 2015 at 04:03:24PM +1100:

> When configuring mdocml from CVS (2015-11-07 11:47AEST), I noticed
> that 'configure' did not find sqlite, which on my system is not in
> /usr/local or /usr.
> 
> Investigations showed that neither CPPFLAGS or LDFLAGS are used by the
> 'configure' script.

If *any* environment variables would be picked up by ./configure,
i would consider that a bug.  I specifically designed ./configure
to make sure that nothing can leak in behind the user's back from
the environment.

> Adding to 'configure.local' the following:
> 
> CC="${CC}"
> CFLAGS="${CPPFLAGS} ${CFLAGS} ${LDFLAGS}" # No support for CPPFLAGS /
> LDFLAGS
> 
> Fixed the issue, and sqlite was found.

Well, i'd suggest to put there what you actually need and want to
use rather than blindly picking up random stuff from the environment.
I mean, the environment might contain god knows what, i cannot
believe you want to depend on that.

> Investigating further, I found the 'Makefile' does use LDFLAGS,

OUCH.  That was a bad bug.  I have no idea how that ended up there.
A variable in the Makefile that was defined absolutely nowhere?
Very strange.  Fixed, thanks for the report.

> My understanding (likely derived from GNU make(1), which I use
> extensively), is that CPPFLAGS, LDFLAGS and LIBS are the standard
> make(1) / environment variables to control the search paths and
> additional required libraries. As in,
> 
>   CPPFLAGS: For -I<path>, -D<var>[=<value>] and -U<var>
>   LDFLAGS:  For -L<path> and -R<path>
>   LIBS:     For -l<library> (eg -lrt for nanosleep() on Solaris 10)

Huh?  A properly set up system ought to work without any environment
variables for standard builds.  If make requires any environment
variables for normal operation, i consider the system broken.

Here is what i have on my system:

   $ ksh -l
   $ echo $CPPFLAGS
  
   $ echo $CFLAGS
  
   $ echo $LDFLAGS
  
   $ echo $LIBS
  
   $ echo $LDADD
  
   $ echo $CC
  
   $ exit

> Question: Should 'configure' and 'Makefile' be using CPPFLAGS and
> LDFLAGS by default? So that the person building the mdocml project
> does not need to provide additional configuration for the build
> process.

No.  Certainly not.  The only non-standard library used is sqlite3,
and if that's in a non-standard path, it's certainly best to specify
it explicitly.

If any standard libraries are in non-standard paths, you should set
that up explicitly in configure.local.  I mean, after all, setting
any such variables changes the system compilers notion about where
his own system libraries are, and that certainly shouldn't be
tinkered with lightly.  I really think that normally, the system
compiler knows best where its own C library is, and certainly doesn't
need whatever may be in the individual end user's environment to
learn that!

Also, there is no need for so many different variables in the mandoc
build system.  Just CFLAGS and LDADD are sufficient for all purposes
encountered so far.

> PPS: My own FLOSS build system has for 64-bit:
> 
>     % env | egrep 'FLAGS|LIBS'
>     LDFLAGS=-L/pkgs/64-bit/lib/amd64 -L/pkgs/64-bit/lib
>     CPPFLAGS=-I/pkgs/64-bit/include -I/pkgs/include
> 
> and for 32-bit:
> 
>     % env | egrep 'FLAGS|LIBS'
>     LDFLAGS=-L/pkgs/32-bit/lib
>     CPPFLAGS=-I/pkgs/32-bit/include -I/pkgs/include

That sounds very "Intel i386 only"; i don't think it makes much
sense for any other processor architecture.

Yours,
  Ingo


 ----- 8< ----- schnipp ----- >8 ----- 8< ----- schnapp ----- >8 -----

Log Message:
-----------
Delete useless variables that could sneak into the Makefile
behind the user's back, dangerously bypassing ./configure.
Leakage reported by Peter Bray <pdb_ml at yahoo dot com dot au>.

Modified Files:
--------------
    mdocml:
        Makefile

Revision Data
-------------
Index: Makefile
===================================================================
RCS file: /home/cvs/mdocml/mdocml/Makefile,v
retrieving revision 1.482
retrieving revision 1.483
diff -LMakefile -LMakefile -u -p -r1.482 -r1.483
--- Makefile
+++ Makefile
@@ -406,22 +406,22 @@ Makefile.local config.h: configure ${TES
 	@exit 1
 
 libmandoc.a: $(COMPAT_OBJS) $(LIBMANDOC_OBJS)
-	$(AR) rs $@ $(COMPAT_OBJS) $(LIBMANDOC_OBJS)
+	ar rs $@ $(COMPAT_OBJS) $(LIBMANDOC_OBJS)
 
 mandoc: $(MAIN_OBJS) libmandoc.a
-	$(CC) $(LDFLAGS) -o $@ $(MAIN_OBJS) libmandoc.a $(LDADD)
+	$(CC) -o $@ $(MAIN_OBJS) libmandoc.a $(LDADD)
 
 manpage: $(MANPAGE_OBJS) libmandoc.a
-	$(CC) $(LDFLAGS) -o $@ $(MANPAGE_OBJS) libmandoc.a $(LDADD)
+	$(CC) -o $@ $(MANPAGE_OBJS) libmandoc.a $(LDADD)
 
 man.cgi: $(CGI_OBJS) libmandoc.a
-	$(CC) $(LDFLAGS) $(STATIC) -o $@ $(CGI_OBJS) libmandoc.a $(LDADD)
+	$(CC) $(STATIC) -o $@ $(CGI_OBJS) libmandoc.a $(LDADD)
 
 demandoc: $(DEMANDOC_OBJS) libmandoc.a
-	$(CC) $(LDFLAGS) -o $@ $(DEMANDOC_OBJS) libmandoc.a $(LDADD)
+	$(CC) -o $@ $(DEMANDOC_OBJS) libmandoc.a $(LDADD)
 
 soelim: $(SOELIM_OBJS)
-	$(CC) $(LDFLAGS) -o $@ $(SOELIM_OBJS)
+	$(CC) -o $@ $(SOELIM_OBJS)
 
 # --- maintainer targets ---
 
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv