[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: autoconf/tools produces to many top level files
From: |
Bob Rossi |
Subject: |
Re: autoconf/tools produces to many top level files |
Date: |
Fri, 12 Apr 2013 22:02:36 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Apr 12, 2013 at 06:49:59AM -0600, Eric Blake wrote:
> On 04/12/2013 05:30 AM, Bob Rossi wrote:
> > Hi,
> >
> > I'm creating a new project and using autotools. I've done this before,
> > but for some reason this time I've noticed how many files autotools
> > creates. It totally pollutes the top level of my project.
> >
> > lib <- Mine originally
> > aclocal.m4
>
> Ask automake if that can be moved. Autoconf does not create it.
Wow! Thanks for this information, very helpful!
I didn't solve aclocal.m4 yet, but..
> > AUTHORS
>
> GNU Coding Standards requires this in the top level; but you can tell
> automake that you don't want to comply to GNU Coding Standards if you
> want to omit it. Autoconf does not create it.
Done --foreign to automake.
> > autom4te.cache
>
> Autoconf creates this, but it is local only; it is not packaged into
> your tarballs. If you don't like it, you can use autom4te's --no-cache
> option (your runs of autoconf will be slightly slower).
A nice feature request would be to move this into one of the directories
specified here,
AC_CONFIG_AUX_DIR(build/build-aux)
AC_CONFIG_MACRO_DIR(build/m4)
AM_CONFIG_HEADER(build/config.h)
or into a new one?
> > bootstrap
>
> Autotools don't create this. That must be your doing, or else you are
> using gnulib.
Yes, this is mine. It's my autoreconf script. Does autoreconf work fine
these days? or is there another way to generate all the scripts?
> > build-aux
Done, used a nested path with AC_CONFIG_AUX_DIR.
> This is a subdirectory, precisely to hold a lot more files rather than
> polluting the top level directory.
>
> > ChangeLog
Done --foreign to automake.
> GNU Coding Standards requires this in the top level. Same comments as
> AUTHORS.
>
> > config.h.in
Done, used a nested path with AM_CONFIG_HEADER.
> This does not have to live at the top level. Use
> AC_CONFIG_HEADERS([dir/config.h]) to stick it in a subdirectory instead.
>
> > configure
>
> Mandatory at the top level, for your package to be configured by end users.
OK, great.
> > configure.in
>
> That name is obsolete. You should be using configure.ac these days.
> This file has to exist for you to create configure; and you need to ship
> it to the user to comply with the rules of open source. No easy way to
> stick it in a subdirectory.
OK, great.
> > COPYING
>
> GNU Coding Standards requires this in the top level. Same comments as
> AUTHORS.
Done --foreign to automake.
> > INSTALL
>
> GNU Coding Standards requires this in the top level. Same comments as
> AUTHORS.
Done --foreign to automake.
> > m4
>
> This is a subdirectory so that you don't have to pollute the top level
> with helper .m4 files.
Done, used a nested path with AC_CONFIG_MACRO_DIR.
> > Makefile.am
>
> If you use automake, this is mandatory to comply with the rules of open
> source. You don't have to use automake, in which case you can get away
> without this file.
OK, great.
> > Makefile.in
>
> Mandatory if you want your use to do './configure && make' - configure
> has to create a Makefile from something, after all.
OK, great.
> > NEWS
>
> GNU Coding Standards requires this in the top level. Same comments as
> AUTHORS.
Done --foreign to automake.
> > README
>
> GNU Coding Standards requires this in the top level. Same comments as
> AUTHORS.
Done --foreign to automake.
> > I understand why configure, Makefile.am and bootstrap (autoreconf script)
> > need to exist in this directory.
> >
> > Is it possible to configure the autotools so that everything else gets
> > put somewhere else (like in a nested directory)?
>
> It's possible to configure automake to not enforce GNU Coding Standards
> and drop some of the files, and to use AC_CONFIG_HEADERS to bury
> config.h[.in] in a subdirectory. Beyond that, it's already a pretty
> minimal list, and nothing listed above is really autoconf's fault except
> for autom4te.cache (which can be disabled), so you are better off
> complaining to other lists.
Thanks again for the help. I got the list down to,
aclocal.m4 <- ask automake
bootstrap <- my autoreconf script
configure
Makefile.am
autom4te.cache <- autoconf feature request to move to build/ dir
build
configure.ac
Makefile.in
src
I'd like to still move aclocal.m4 and autom4te.cache if possible.
We'll see.
Bob