help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Peter Bray <pdb_ml@yahoo.com.au>
Cc: discuss@mdocml.bsd.lv
Subject: Re: mdocml [CVS_2015_11_07] Use of CPPFLAGS and LDFLAGS
Date: Thu, 19 May 2016 02:26:39 +0200	[thread overview]
Message-ID: <20160519002639.GM27511@athene.usta.de> (raw)
In-Reply-To: <563D861C.2010902@yahoo.com.au>

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}"
> 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.


 ----- 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:

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)
 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

      reply	other threads:[~2016-05-19  0:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-07  5:03 Peter Bray
2016-05-19  0:26 ` Ingo Schwarze [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160519002639.GM27511@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=discuss@mdocml.bsd.lv \
    --cc=pdb_ml@yahoo.com.au \
    --subject='Re: mdocml [CVS_2015_11_07] Use of CPPFLAGS and LDFLAGS' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).