autoconf/tools produces to many top level files
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 AUTHORS autom4te.cache bootstrap build-aux ChangeLog config.h.in configure configure.in COPYING INSTALL m4 Makefile.am Makefile.in NEWS README 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)? Thanks, Bob Rossi ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf/tools produces to many top level files
Hi, On Fri, Apr 12, 2013 at 1:30 PM, Bob Rossi b...@brasko.net 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 AUTHORS autom4te.cache bootstrap build-aux ChangeLog config.h.in configure configure.in COPYING INSTALL m4 Makefile.am Makefile.in NEWS README 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)? Look for the macros AC_CONFIG_AUX_DIR(), AC_CONFIG_MACRO_DIR(), and AC_CONFIG_HEADERS() Hth, Bert Thanks, Bob Rossi ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf/tools produces to many top level files
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. 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. 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). bootstrap Autotools don't create this. That must be your doing, or else you are using gnulib. build-aux This is a subdirectory, precisely to hold a lot more files rather than polluting the top level directory. ChangeLog GNU Coding Standards requires this in the top level. Same comments as AUTHORS. config.h.in 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. 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. COPYING GNU Coding Standards requires this in the top level. Same comments as AUTHORS. INSTALL GNU Coding Standards requires this in the top level. Same comments as AUTHORS. m4 This is a subdirectory so that you don't have to pollute the top level with helper .m4 files. 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. Makefile.in Mandatory if you want your use to do './configure make' - configure has to create a Makefile from something, after all. NEWS GNU Coding Standards requires this in the top level. Same comments as AUTHORS. README GNU Coding Standards requires this in the top level. Same comments as AUTHORS. 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. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Link tests when cross compiling
Why are link tests not allowed when cross compiling? You don't have to run the exe to verify that linking worked. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Link tests when cross compiling
On 04/12/2013 02:20 PM, NightStrike wrote: Why are link tests not allowed when cross compiling? You don't have to run the exe to verify that linking worked. What gave you the impression that link tests are not allowed when cross compiling? We use link tests all the time. It is run tests that require a fallback when cross-compiling, not link tests. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Link tests when cross compiling
On Fri, Apr 12, 2013 at 10:26 AM, Eric Blake ebl...@redhat.com wrote: On 04/12/2013 02:20 PM, NightStrike wrote: Why are link tests not allowed when cross compiling? You don't have to run the exe to verify that linking worked. What gave you the impression that link tests are not allowed when cross compiling? We use link tests all the time. It is run tests that require a fallback when cross-compiling, not link tests. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org checking for main in -lpthread... configure: error: link tests are not allowed after AC_NO_EXECUTABLES That's me trying to use AC_CHECK_LIB when cross compiling. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Link tests when cross compiling
On Friday 12 April 2013 16:38:29 NightStrike wrote: On Fri, Apr 12, 2013 at 10:26 AM, Eric Blake wrote: On 04/12/2013 02:20 PM, NightStrike wrote: Why are link tests not allowed when cross compiling? You don't have to run the exe to verify that linking worked. What gave you the impression that link tests are not allowed when cross compiling? We use link tests all the time. It is run tests that require a fallback when cross-compiling, not link tests. checking for main in -lpthread... configure: error: link tests are not allowed after AC_NO_EXECUTABLES That's me trying to use AC_CHECK_LIB when cross compiling. please post full config.logs. what you've shown is that your compiler has been flagged as not being able to produce executables which is very different from is it a cross-compiler. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Link tests when cross compiling
On Fri, Apr 12, 2013 at 10:44 AM, Mike Frysinger vap...@gentoo.org wrote: On Friday 12 April 2013 16:38:29 NightStrike wrote: On Fri, Apr 12, 2013 at 10:26 AM, Eric Blake wrote: On 04/12/2013 02:20 PM, NightStrike wrote: Why are link tests not allowed when cross compiling? You don't have to run the exe to verify that linking worked. What gave you the impression that link tests are not allowed when cross compiling? We use link tests all the time. It is run tests that require a fallback when cross-compiling, not link tests. checking for main in -lpthread... configure: error: link tests are not allowed after AC_NO_EXECUTABLES That's me trying to use AC_CHECK_LIB when cross compiling. please post full config.logs. what you've shown is that your compiler has been flagged as not being able to produce executables which is very different from is it a cross-compiler. -mike Attached. Interesting, though, when I don't cross compile, the check executes. And, I've always seen this when I try to cross compile. I must have something fundamentally wrong in my understanding. Hopefully, the attached log helps you to enlighten me. config.log Description: Binary data ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
How does one configure in directories with special characters in them?
Hello, I am running on Linux (Fedora 17 to be exact) and have a directory called: /home/jjohnstn/runtime-NewConfiguration(2)/hello The directory was generated by Eclipse as a workspace directory. It defaults the name each time and adds numerics if the default name is already in use. What is happening is that I have a simple configure.ac for a hello world program: dnl Process this file with autoconf to produce a configure script. AC_PREREQ(2.59) AC_INIT(hello, 1.0) AC_CANONICAL_SYSTEM AM_INIT_AUTOMAKE() AC_PROG_CC AC_CONFIG_FILES(Makefile src/Makefile) AC_OUTPUT When I try to configure it, there is a generated call to missing and the call adds the directory name it has calculated but it fails because the () chars are not escaped. This occurs whether I change to the directory and run it as ./configure or whether I specify an absolute directory and escape the () chars myself. Is there a way for me to get around this or this is simply a bug? I am using autoconf 2.68 Thanks, -- Jeff J. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Link tests when cross compiling
On 04/12/2013 02:47 PM, NightStrike wrote: What gave you the impression that link tests are not allowed when cross compiling? We use link tests all the time. It is run tests that require a fallback when cross-compiling, not link tests. checking for main in -lpthread... configure: error: link tests are not allowed after AC_NO_EXECUTABLES AC_NO_EXECUTABLES is intentionally not documented in the autoconf manual; here are the comments at its m4 definition: # AC_NO_EXECUTABLES # - # FIXME: The GCC team has specific needs which the current Autoconf # framework cannot solve elegantly. This macro implements a dirty # hack until Autoconf is able to provide the services its users # need. # # Several of the support libraries that are often built with GCC can't # assume the tool-chain is already capable of linking a program: the # compiler often expects to be able to link with some of such # libraries. # # In several of these libraries, workarounds have been introduced to # avoid the AC_PROG_CC_WORKS test, that would just abort their # configuration. The introduction of AC_EXEEXT, enabled either by # libtool or by CVS autoconf, have just made matters worse. # # Unlike an earlier version of this macro, using AC_NO_EXECUTABLES does # not disable link tests at autoconf time, but at configure time. # This allows AC_NO_EXECUTABLES to be invoked conditionally. That's me trying to use AC_CHECK_LIB when cross compiling. Why are you using AC_NO_EXECUTABLES? Are you working on gcc? If so, this question is better asked on the gcc list. If not, then don't use it. please post full config.logs. what you've shown is that your compiler has been flagged as not being able to produce executables which is very different from is it a cross-compiler. -mike Attached. Interesting, though, when I don't cross compile, the check executes. And, I've always seen this when I try to cross compile. I must have something fundamentally wrong in my understanding. Hopefully, the attached log helps you to enlighten me. The reason that gcc rejects link tests is because of historical baggage of how the uber-tree is used to build an entire cross environment (libraries, gcc, gdb, and more, all in one go) - in THAT environment, configure can't perform link tests, because the tests would have to link against the cross-built libraries, but this is the configure script trying to set up those cross-built libraries (they don't exist yet, so the link test will do the wrong thing). Outside of gcc's special needs, you should generally have no problem pre-installing cross-built libraries, at which point, you should have no need for AC_NO_EXECUTABLES in your configure.ac. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How does one configure in directories with special characters in them?
That looks like a bug in Automake, since the code that deals with missing is generated by Automake. Could you please send a self-contained example of the bug to bug-autom...@gnu.org? Thanks. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Link tests when cross compiling
On Fri, Apr 12, 2013 at 11:15 AM, Eric Blake ebl...@redhat.com wrote: On 04/12/2013 02:47 PM, NightStrike wrote: What gave you the impression that link tests are not allowed when cross compiling? We use link tests all the time. It is run tests that require a fallback when cross-compiling, not link tests. checking for main in -lpthread... configure: error: link tests are not allowed after AC_NO_EXECUTABLES AC_NO_EXECUTABLES is intentionally not documented in the autoconf manual; here are the comments at its m4 definition: # AC_NO_EXECUTABLES # - # FIXME: The GCC team has specific needs which the current Autoconf # framework cannot solve elegantly. This macro implements a dirty # hack until Autoconf is able to provide the services its users # need. # # Several of the support libraries that are often built with GCC can't # assume the tool-chain is already capable of linking a program: the # compiler often expects to be able to link with some of such # libraries. # # In several of these libraries, workarounds have been introduced to # avoid the AC_PROG_CC_WORKS test, that would just abort their # configuration. The introduction of AC_EXEEXT, enabled either by # libtool or by CVS autoconf, have just made matters worse. # # Unlike an earlier version of this macro, using AC_NO_EXECUTABLES does # not disable link tests at autoconf time, but at configure time. # This allows AC_NO_EXECUTABLES to be invoked conditionally. That's me trying to use AC_CHECK_LIB when cross compiling. Why are you using AC_NO_EXECUTABLES? Are you working on gcc? If so, this question is better asked on the gcc list. If not, then don't use it. I swear I grepped for that and didn't see it before I ever emailed the list. *sigh*... This is for a pthread replacement library that should be compilable before we have a working compiler. I did not make the initial build system for this, so I have to see what problem this macro is trying to solve. Conceivably, though, we should be able to turn it on conditionally in the worst case instead of all the time. IOW, only use it if we are bootstrapping. What I want to ultimately do is actually test to see if we are in said bootstrap environment. In that case, we need to build a fake libgcc to link in. Any idea how to do that? please post full config.logs. what you've shown is that your compiler has been flagged as not being able to produce executables which is very different from is it a cross-compiler. -mike Attached. Interesting, though, when I don't cross compile, the check executes. And, I've always seen this when I try to cross compile. I must have something fundamentally wrong in my understanding. Hopefully, the attached log helps you to enlighten me. The reason that gcc rejects link tests is because of historical baggage of how the uber-tree is used to build an entire cross environment (libraries, gcc, gdb, and more, all in one go) - in THAT environment, configure can't perform link tests, because the tests would have to link against the cross-built libraries, but this is the configure script trying to set up those cross-built libraries (they don't exist yet, so the link test will do the wrong thing). Outside of gcc's special needs, you should generally have no problem pre-installing cross-built libraries, at which point, you should have no need for AC_NO_EXECUTABLES in your configure.ac. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Link tests when cross compiling
On Friday 12 April 2013 18:02:36 NightStrike wrote: This is for a pthread replacement library that should be compilable before we have a working compiler. I did not make the initial build system for this, so I have to see what problem this macro is trying to solve. Conceivably, though, we should be able to turn it on conditionally in the worst case instead of all the time. IOW, only use it if we are bootstrapping. What I want to ultimately do is actually test to see if we are in said bootstrap environment. In that case, we need to build a fake libgcc to link in. Any idea how to do that? glibc already does this for its initial bootstrap. but this line of questioning doesn't make much sense on the autoconf list. this should be gcc and/or glibc's libc-help. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf/tools produces to many top level files
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 ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autoconf/tools produces to many top level files
Bob Rossi b...@brasko.net writes: On Fri, Apr 12, 2013 at 06:49:59AM -0600, Eric Blake wrote: On 04/12/2013 05:30 AM, Bob Rossi wrote: 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.. You can tell aclocal to write the file somewhere else (with --output). You may want to try just putting it into your AC_CONFIG_MACRO_DIR and see if it happens to work. Although that's going to force you to keep your bootstrap script, since that means calling aclocal with a flag instead of just running autoreconf. 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? autoreconf just works, and I would pass it --no-cache. I always suppress the cache and don't really notice a significant difference. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
