help / color / mirror / Atom feed
From: Peter Bray <pdb_ml@yahoo.com.au>
To: discuss@mdocml.bsd.lv
Subject: mdocml [CVS_2015_11_07] Use of CPPFLAGS and LDFLAGS
Date: Sat, 07 Nov 2015 16:03:24 +1100	[thread overview]
Message-ID: <563D861C.2010902@yahoo.com.au> (raw)


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:


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


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'
     CPPFLAGS=-I/pkgs/32-bit/include -I/pkgs/include

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

             reply	other threads:[~2015-11-07  5:03 UTC|newest]

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

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=563D861C.2010902@yahoo.com.au \
    --to=pdb_ml@yahoo.com.au \
    --cc=discuss@mdocml.bsd.lv \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).