From: Ted Ts'o <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>, xfs@oss.sgi.com
Subject: Re: [PATCH XFSPROGS 2/3] Build without enabling DEBUG by default
Date: Fri, 22 Jul 2011 18:34:58 -0400 [thread overview]
Message-ID: <20110722223458.GD25092@thunk.org> (raw)
In-Reply-To: <20110722183830.GA21744@infradead.org>
On Fri, Jul 22, 2011 at 02:38:30PM -0400, Christoph Hellwig wrote:
>
> You can get most of this by simply using make V=1, not just in xfsprogs,
> but in most projects using silent make output (including those using
> automake)
Yeah, I know about V=1 (and I have been using it), but I wanted to
know which of the many Makefile variables which finally make up
$(CFLAGS) was getting set to which value, and V=1 doesn't do this.
> for me. The biggest thing is that you have another directory in your
> include path. How did you add that one? Did you add anything else
> special to the ./configure or make command lines?
Yes I needed it because I wanted to do a hermetic build; that is, I
didn't want to depend on the version of the acl, attr, dmapi, etc.,
shipped by the distribution. (This is actually more important when
building xfstests, since I wanted to make sure we used the version of
the xfsprogs headers shipped by the very tip of xfsprogs-dev, since in
the past I've had problems because the distro-shipped header files
were too old.)
The way I did that was by setting the environment CFLAGS to
-I/kbuild/xfstests/bld/include. And that seems to be the problem. If
CFLAGS is set as an environment variable, then it's set as a :=, which
means that CFLAGS is set right away, the first time buildmacros is
included.
How about this instead? A patch like this so that CFLAGS can be
remembered at configure time:
diff --git a/include/builddefs.in b/include/builddefs.in
index 4c8ec64..81ebfcd 100644
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -25,6 +25,7 @@ OPTIMIZER = @opt_build@
MALLOCLIB = @malloc_lib@
LOADERFLAGS = @LDFLAGS@
LTLDFLAGS = @LDFLAGS@
+CFLAGS = @CFLAGS@
LIBRT = @librt@
LIBUUID = @libuuid@
Then I don't have to set an environment variable when running make; I
just have to pass it to configure.
- Ted
WARNING: multiple messages have this Message-ID (diff)
From: "Ted Ts'o" <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>, xfs@oss.sgi.com
Subject: Re: [PATCH XFSPROGS 2/3] Build without enabling DEBUG by default
Date: Fri, 22 Jul 2011 18:34:58 -0400 [thread overview]
Message-ID: <20110722223458.GD25092@thunk.org> (raw)
In-Reply-To: <20110722183830.GA21744@infradead.org>
On Fri, Jul 22, 2011 at 02:38:30PM -0400, Christoph Hellwig wrote:
>
> You can get most of this by simply using make V=1, not just in xfsprogs,
> but in most projects using silent make output (including those using
> automake)
Yeah, I know about V=1 (and I have been using it), but I wanted to
know which of the many Makefile variables which finally make up
$(CFLAGS) was getting set to which value, and V=1 doesn't do this.
> for me. The biggest thing is that you have another directory in your
> include path. How did you add that one? Did you add anything else
> special to the ./configure or make command lines?
Yes I needed it because I wanted to do a hermetic build; that is, I
didn't want to depend on the version of the acl, attr, dmapi, etc.,
shipped by the distribution. (This is actually more important when
building xfstests, since I wanted to make sure we used the version of
the xfsprogs headers shipped by the very tip of xfsprogs-dev, since in
the past I've had problems because the distro-shipped header files
were too old.)
The way I did that was by setting the environment CFLAGS to
-I/kbuild/xfstests/bld/include. And that seems to be the problem. If
CFLAGS is set as an environment variable, then it's set as a :=, which
means that CFLAGS is set right away, the first time buildmacros is
included.
How about this instead? A patch like this so that CFLAGS can be
remembered at configure time:
diff --git a/include/builddefs.in b/include/builddefs.in
index 4c8ec64..81ebfcd 100644
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -25,6 +25,7 @@ OPTIMIZER = @opt_build@
MALLOCLIB = @malloc_lib@
LOADERFLAGS = @LDFLAGS@
LTLDFLAGS = @LDFLAGS@
+CFLAGS = @CFLAGS@
LIBRT = @librt@
LIBUUID = @libuuid@
Then I don't have to set an environment variable when running make; I
just have to pass it to configure.
- Ted
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-07-22 22:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-21 23:50 [PATCH XFSPROGS 1/3] configure.in: Declare a requirement for at least autoconf 2.50 Theodore Ts'o
2011-07-21 23:50 ` Theodore Ts'o
2011-07-21 23:50 ` [PATCH XFSPROGS 2/3] Build without enabling DEBUG by default Theodore Ts'o
2011-07-21 23:50 ` Theodore Ts'o
2011-07-22 14:17 ` Christoph Hellwig
2011-07-22 14:17 ` Christoph Hellwig
2011-07-22 18:30 ` Ted Ts'o
2011-07-22 18:30 ` Ted Ts'o
2011-07-22 18:38 ` Christoph Hellwig
2011-07-22 18:38 ` Christoph Hellwig
2011-07-22 22:30 ` Alex Elder
2011-07-22 22:30 ` Alex Elder
2011-07-22 22:34 ` Ted Ts'o [this message]
2011-07-22 22:34 ` Ted Ts'o
2011-07-23 1:32 ` Christoph Hellwig
2011-07-23 1:32 ` Christoph Hellwig
2011-07-26 15:10 ` Christoph Hellwig
2011-07-26 15:10 ` Christoph Hellwig
2011-07-30 16:55 ` Christoph Hellwig
2011-07-30 16:55 ` Christoph Hellwig
2011-08-01 21:58 ` [PATCH] Build using CFLAGS passed in at configure Theodore Ts'o
2011-08-01 21:58 ` Theodore Ts'o
2011-08-02 10:03 ` Christoph Hellwig
2011-08-02 10:03 ` Christoph Hellwig
2011-07-21 23:50 ` [PATCH XFSPROGS 3/3] mkfs: Link against libuuid after liblkid Theodore Ts'o
2011-07-21 23:50 ` Theodore Ts'o
2011-07-22 14:29 ` Christoph Hellwig
2011-07-22 14:29 ` Christoph Hellwig
2011-07-22 14:28 ` [PATCH XFSPROGS 1/3] configure.in: Declare a requirement for at least autoconf 2.50 Christoph Hellwig
2011-07-22 14:28 ` Christoph Hellwig
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110722223458.GD25092@thunk.org \
--to=tytso@mit.edu \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.