Re: Automake Digest, Vol 133, Issue 5

[PenguinDude24]

On 12/16/2013 12:00 PM, address@hidden wrote:
> Send Automake mailing list submissions to
>         address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/automake
> or, via email, send a message with subject or body 'help' to
>         address@hidden
>
> You can reach the person managing the list at
>         address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Automake digest..."
>
>
> Today's Topics:
>
>     1. Re: automake breaks my file by putting includes after rules;
>        how do I fix this? (Jason Gross)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 16 Dec 2013 10:49:49 -0500
> From: Jason Gross<address@hidden>
> To: Gavin Smith<address@hidden>
> Cc: Automake Mailing List<address@hidden>
> Subject: Re: automake breaks my file by putting includes after rules;
>         how do I        fix this?
> Message-ID:
>         <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> These compiled files get distributed/installed, so I think they belong in
> DATA.
>
> The solution I ended up using was manually including an "all-am" target
> below the definition, which overrides the one that automake generates.
>
> I think the other contributors to the project would complain only slightly
> less about depending on automake than they did about depending on
> autoreconf (I ended up setting up an extra branch of the source repo which
> the autogenerated files get automatically pushed to); the intended
> contributors/users of the source repo are mathematicians who may have
> little to no programming experience.
>
> -Jason
>
>
> On Mon, Dec 2, 2013 at 8:10 AM, Gavin Smith<address@hidden>wrote:
>
> > On Wed, Nov 20, 2013 at 9:33 PM, Jason Gross<address@hidden>
> > wrote:
> > > I have a Makefile.am which includes another file in order to get a list
> > of
> > > files it should compile (I don't want to require running autoreconf and
> > > configure whenever you add a file that the makefile already knows how to
> > > compile).  But this does not work with automake's generated all and
> > all-am
> > > targets, which compute their dependencies on the basis of the DATA
> > > variable, which is auto-defined to be nobase_hott_DATA, which depends on
> > > variables set in the included file.  How do I fix this?  (Should I
> > submit a
> > > bug report that includes should come before the autogenerated targets?)
> > Is it possible to use the "all-local" target to compile these files,
> > and use another variable to list the files instead of DATA?
>
>
> ------------------------------
>
> _______________________________________________

First off, forcing your own 'all-am' target is considered gross 
malpractice. Your going to hurt yourself with that. Do not do that. The 
recommended course for your case is to use a target, namely 
'install-data-hook' in the source Makefile.am. BUT, that is in most 
cases the worst case scenario. Based on what you told me, I think that 
you can get by with the regular Autotools facilites. Why else would you 
use Autotools?

Read along to find out the regular and recommended way.

You did not provide any scrubbed example of what you are working with, 
so I will rub something together.

# filename      --      Makefile.am
# ---------------------------------

# ... lines in the Makefile.am before this stage, such as
# SUBDIR directive, or other directive like LTLIBRARIES or
# other AutoMake directives (that will generate stuff in
# the generated Makefiles).

# We list the data files for your package -- just an example.
# Note, the dist prefix addition on the DATA directive is mandatory
# else your data files will not be distributed. DATA files are not
# shipped by defualt!
dist_pkgdata_DATA = root-datafile-1.bin correlations.csv \
        data-f0.bin data-f1.bin data-f2.bin

# Then, you must include a 'dummy rule' (even though its a 'dummy rule')
# to make that list of files. Here is the rule to build
# dist_pkgdata_DATA items.
# --

$(dist_pkgdata_DATA):
        @echo 'Dummy rule NO-OP for: ' $@

Without the dummy rule, the generated Makefile(s) are worthless. GNU 
Make (and all the rest of them) will tell you, or something similar, "No 
rule to make 'targetname' " and exit with fatal error.

For the grand finale, when you run './configure && make && make install' 
cmds, the data files will reside in ( prefix = '/usr/local' and 
datarootdir = "$prefix/$share"):

In bash run:

ls 
$(prefix)/$(datarootdir)/$(your_package_name_in_configure.ac)/{root-datafile-1.bin,correlations.csv, 
... etc}


Then, it is up to your application to find the data files in 
/usr/local/share/your-pkg-name/datafile-1.bin, and the rest of them.

And when you are using autoreconf, you have to export certain variables 
into the environment for them to work. There are many env vars that it 
can take, but the ones that are vital are:
AUTOCONF
AUTOHEADER
AUTOM4TE
AUTOMAKE
ACLOCAL
LIBTOOLIZE

Else, when you run autoreconf, the versions it runs may be different 
because there are many auto*foo* versions installed in one system at one 
time. Then you normally have to invoke libtoolize (if your building 
libs) before you run autoreconf. And you can pass flags to autoreconf 
like -I (so that the tools it run can use it).

I got this from the perl script /usr/bin/automake:
my $autoconf   = $ENV{'AUTOCONF'}   || '/usr/bin/autoconf';
my $autoheader = $ENV{'AUTOHEADER'} || '/usr/bin/autoheader';
my $autom4te   = $ENV{'AUTOM4TE'}   || '/usr/bin/autom4te';
my $automake   = $ENV{'AUTOMAKE'}   || 'automake';
my $aclocal    = $ENV{'ACLOCAL'}    || 'aclocal';
my $libtoolize = $ENV{'LIBTOOLIZE'} || 'libtoolize';
my $autopoint  = $ENV{'AUTOPOINT'}  || 'autopoint';
my $make       = $ENV{'MAKE'}       || 'make';

Good luck!