nodist_BUILT_SOURCES?

2010-06-10 Thread Monty Taylor
Hey all,

Potentially odd question...

How would I accomplish something like what's in the subject? I have a
source file that wants to be built before other files - so including it
in BUILT_SOURCES does the right thing, but I do _not_ want to have it
included in the dist tarball.

I tried removing it from BUILT_SOURCES and adding in a rule that looks like:

%.cc: drizzled/configmake.h

But that didn't work.

Any thoughts?

While we're at it - this whole thing is to get expanded values of
autoconf directories into a header file where I can consume them...
which because they contain nested variables
(localstatedir=${prefix}/var}) I seemingly have to do at make time. The
dist problem above could be solved if anybody knows a decent trick to
fully expand those variables at configure time... I've tried many
combinations of eval and quoting - but nothing seems to do what I'm
trying to do.

Thanks!
Monty



Re: nodist_BUILT_SOURCES?

2010-06-10 Thread Ralf Wildenhues
Hello Monty,

first of all, let's ditch the cross-post, this is an Automake question
(and the interested readers read both lists anyway).

* Monty Taylor wrote on Thu, Jun 10, 2010 at 07:42:13PM CEST:
 How would I accomplish something like what's in the subject? I have a
 source file that wants to be built before other files - so including it
 in BUILT_SOURCES does the right thing, but I do _not_ want to have it
 included in the dist tarball.

What makes you think BUILT_SOURCES end up being put in the dist tarball?
Just listing something there does not do that, so it must be something
else in your Makefile.am.

Please show it, or better, a small reproducible example, and we'll be
able to quickly spot the issue here.

 While we're at it - this whole thing is to get expanded values of
 autoconf directories into a header file where I can consume them...
 which because they contain nested variables
 (localstatedir=${prefix}/var}) I seemingly have to do at make time. The
 dist problem above could be solved if anybody knows a decent trick to
 fully expand those variables at configure time... I've tried many
 combinations of eval and quoting - but nothing seems to do what I'm
 trying to do.

OK, well, I'm still clueless as to what you're doing, so I can recommend
  info Autoconf Defining Directories

and showing us what you got.  Please don't send generated files, and
please only to one list, and please pack large files with gzip.

Thanks,
Ralf



Re: nodist_BUILT_SOURCES?

2010-06-10 Thread John Calcote
Hi Monty,

On 6/10/2010 11:42 AM, Monty Taylor wrote:
 Hey all,

 Potentially odd question...

 How would I accomplish something like what's in the subject? I have a
 source file that wants to be built before other files - so including it
 in BUILT_SOURCES does the right thing, but I do _not_ want to have it
 included in the dist tarball.

   

Files listed in BUILT_SOURCES are not taken into account wrt
distribution. The distribution list is built from other primary-like
constructs, such as *_SOURCES. The example in the autoconf manual shows
how you would do what you want:

...
nodist_foo_SOURCES = bindir.h
BUILT_SOURCES = bindir.h
...

In this example, BUILT_SOURCES is used only to get bindir.h built up
front. The actual SOURCES variable used to list its use by a particular
product carries the nodist prefix, which keeps it from being distributed.
I tried removing it from BUILT_SOURCES and adding in a rule that looks like:

 %.cc: drizzled/configmake.h

 But that didn't work.

 Any thoughts?

 While we're at it - this whole thing is to get expanded values of
 autoconf directories into a header file where I can consume them...
 which because they contain nested variables
 (localstatedir=${prefix}/var}) I seemingly have to do at make time. The
 dist problem above could be solved if anybody knows a decent trick to
 fully expand those variables at configure time... I've tried many
 combinations of eval and quoting - but nothing seems to do what I'm
 trying to do.
   

You can't (or rather shouldn't) fully expand these variables at
configure time because they may be modified at make time by the user on
the make command line (e.g., make prefix=xxx). There are two
widely-practiced options:

1. Replace such variables on the compiler command line for all or some
sources:

mylib_la_CPPFLAGS =\
 -DSYSCONFDIR=\$(sysconfdir)\\
 -DSYSLOGDIR=\$(syslogdir)\ ...

This works well for situations where you only have a few variables to
replace.

2. Add some custom rules to your Makefile.am scripts that build your
source files using variable replacement techniques like those used by
Autoconf:

EXTRA_DIST = myprog.cfg.in

edit = sed \
   -e 's|@sysconfd...@]|$(sysconfdir)|g' \
   -e 's|@sysrund...@]|$(sysrundir)|g' \
   -e 's|@syslogd...@]|$(syslogdir)|g' \
   -e 's|@libexecd...@]|$(libexecdir)|g' \
   -e 's|@sbind...@]|$(sbindir)|g'\
   -e 's|@pref...@]|$(prefix)|g'

all: myprog.cfg

# Build executable scripts
myprog.cfg : Makefile
$(edit) '$(srcdir)/$...@.in'  $@

Then just format your input templates just like autoconf input templates
with @variable@ where ever you want variable replacement to occur at
make time.

Regards,
John




Re: nodist_BUILT_SOURCES?

2010-06-10 Thread Monty Taylor
On 06/10/2010 11:10 AM, Ralf Wildenhues wrote:
 Hello Monty,
 
 first of all, let's ditch the cross-post, this is an Automake question
 (and the interested readers read both lists anyway).
 
 * Monty Taylor wrote on Thu, Jun 10, 2010 at 07:42:13PM CEST:
 How would I accomplish something like what's in the subject? I have a
 source file that wants to be built before other files - so including it
 in BUILT_SOURCES does the right thing, but I do _not_ want to have it
 included in the dist tarball.
 
 What makes you think BUILT_SOURCES end up being put in the dist tarball?
 Just listing something there does not do that, so it must be something
 else in your Makefile.am.
 
 Please show it, or better, a small reproducible example, and we'll be
 able to quickly spot the issue here.

YES! You are right. Some how I missed an entry in an included file that
was including the file. Sorry for the false query - I looked through
several times and just didn't see the entry.

/me FAIL