Re: variables in _SOURCES
Daniel, this is still a known bug in released versions of autotools, see http://debbugs.gnu.org/13928 Best, Bert On Sun, Jun 12, 2016 at 9:22 AM, Daniel Pocock wrote: > > > According to the "Warning" in this page[1], it is not permitted to use > variables in _SOURCES. Is this deliberate or is it a bug? > > In our project, we started getting the warnings about subdir-objects and > so we added[2] > > AM_INIT_AUTOMAKE([foreign subdir-objects]) > > However, since that time the build has been failing[3] and it appears to > be because one module[4] is using a variable in _SOURCES > > The $PYCXX_SRCDIR variable is used to refer to the sources provided by > the PyCXX[5] library. PyCXX is not distributed as a compiled library > that can be linked against, the sources are simply placed under > /usr/share by the packages (e.g. on Debian[6]) and users have to compile > them into their projects by referring to them from their Makefile. > > What is the recommended way of using such sources in a build? I could > write some Makefile rule to copy or symlink the sources in to the tree, > but is there an official way to solve this with autotools? > > More specifically, I am using them like this: > > configure: > > ./configure ... \ >--with-python \ >PYCXX_SRCDIR=/usr/share/python2.7/CXX/Python2 > > > Makefile.am: > > nodist_libpyroute_la_SOURCES = $(PYCXX_SRCDIR)/cxxextensions.c > nodist_libpyroute_la_SOURCES += $(PYCXX_SRCDIR)/cxx_extensions.cxx > nodist_libpyroute_la_SOURCES += $(PYCXX_SRCDIR)/cxxsupport.cxx > nodist_libpyroute_la_SOURCES += > $(PYCXX_SRCDIR)/../IndirectPythonInterface.cxx > > > > > 1. https://autotools.io/automake/nonrecursive.html > 2. > https://github.com/resiprocate/resiprocate/commit/fb37bc86db9f1b7d569eb2a17acd1e683b6ce55f > 3. https://travis-ci.org/resiprocate/resiprocate/builds/131873177 > 4. > https://github.com/resiprocate/resiprocate/blob/master/repro/plugins/pyroute/Makefile.am > 5. http://cxx.sourceforge.net/ > 6. > https://packages.debian.org/search?searchon=contents&keywords=cxxextensions.c&mode=path&suite=stable&arch=any > >
Re: Automake 1.15 + subdir-objects using $(top_srcdir) in *_SOURCES
Hi, On Tue, Aug 18, 2015 at 10:08 AM, Tom Ghyselinck wrote: > Hi all, > > I just upgraded to automake-1.15. > > I got a warning about future incompatibilities: > src/Makefile.am:205: warning: source file > 'StackControllers/AbstractController.cpp' is in a subdirectory, > src/Makefile.am:205: but option 'subdir-objects' is disabled > automake: warning: possible forward-incompatibility. > automake: At least a source file is in a subdirectory, but the > 'subdir-objects' > automake: automake option hasn't been enabled. For now, the > corresponding output > automake: object file(s) will be placed in the top-level directory. > However, > automake: this behaviour will change in future Automake versions: they > will > automake: unconditionally cause object files to be placed in the same > subdirectory > automake: of the corresponding sources. > automake: You are advised to start using 'subdir-objects' option > throughout your > automake: project, to avoid future incompatibilities. > > We use "/.cpp" in some "*_SOURCES" entries in our > "Makefile.am" files. > > Since I don't like warnings, I followed the suggestion and added the "s > ubdir-objects" option in our configure.ac. > > Now, in one of our Makefile.am we are using > gtest_SOURCES = $(top_srcdir)/src/globaloptions.cpp ... > > We build our project in /tmp/build. > When trying to execute "make clean" for our project, we get the error: > Making clean in testing > make[2]: Entering directory '/tmp/build/src/testing' > Makefile:1193: /path/to/source/src/.deps/gtest-globaloptions.Po: No such > file or directory > make[2]: *** No rule to make target > '/path/to/source/src/.deps/gtest-globaloptions.Po'. Stop. > make[2]: Leaving directory '/tmp/build/src/testing' > Makefile:1513: recipe for target 'clean-recursive' failed > > Is this a known issue? > Or is it incorrect to use "$(top_srcdir)" in the "*_SOURCES" directive > when using the "subdirs-objects" option? > > We would like to keep using the "$(top_srcdir)" since the subdirs where > the Makefile.am using this resides may move around in the project > directory tree. > > Can anyone explain what is going wrong or how we should update this to > keep this working? > > Thank you in advance! I would say you hit two bugs already fixed after the release of 1.15. http://debbugs.gnu.org/13928 Bert > > With best regards, > Tom. >
Re: Re: why forbidding "include" a sub-makefile.am with absolute path
On Tue, Jun 30, 2015 at 2:16 AM, 远猷 wrote: > thanks for your reply! > > but why forbidding “include” a sub-makefiles.am with absolute path? Do you want to 'include' a 'automake file' fragment so that it is processed when automake is running (mostly done by autoreconf these days) or do you want to include a 'make file' fragment, which is processed when make is run? You are speaking about 'sub-makefiles.am' above, which indicates the former. While your 'common.mk' indicates the latter. To your question at hand, if you have an absolute path to an 'automake file' in an Automake include directive, than this would mean, you are the only person who can run automake in this project. If you want to include a 'make file' at make time, than I suggest you try this: @AMDEP_TRUE@@am__include@ @am__quote@@another_pj_...@common.mk@am__quote@ Now automake generates a include statement which will be processed at make time. HTH, Bert
Re: Part 2: Add Cleanfiles for User Defined Special Sources [Re: How to add new Makefile-Rules through Configure?]
On Tue, Mar 10, 2015 at 11:54 AM, Vincent Torri wrote: > On Tue, Mar 10, 2015 at 10:47 AM, Marc Wäckerlin wrote: >> Any comments on what is a proper solution? >> >> Requirements fo a solution: >> - Add makefile rules from within configure.ac >> - No maual changes in makefile.am files required > > imho, configure.ac is for configuring the project, not defining 'make' > rules. These 'make' rules should go into Makefile.am : > > do-a-test: > @echo "Hey, it works in project: $(PACKAGE_NAME)-$(PACKAGE_VERSION)" > I can only second this. Nobody is forced to use also automake with autoconf. But if your extension require autoconf *and* automake, than you can also insist, that the user of your extension manually edit both, i.e., configure.ac *and* Makefile.am. Bert > Vincent Torri > >
Re: converting to subdir-objects
On Sun, Mar 8, 2015 at 7:33 PM, Bob Friesenhahn wrote: > On Sun, 8 Mar 2015, Bert Wesarg wrote: >>>> >>>> >>>> So if A/Makefile.am contains: >>>> >>>> foo_SRCS = ... $(srcdir)/../foo/bar.c >>> >>> >>> >>> As far as I am aware, it is wise/required that source paths be >>> subordinate >>> to the Makefile.am location (no .. bits). >> >> >> If that would really be a requirement now or with subdir-objects, I >> would say its a regression. > > > I checked the current Automake manual and am not able to find any text which > says that a subdirectory needs to be a subdirectory of where the Makefile > resides. What is a subdirectory anyway? The generated Makefile would > include per-source-file target specifications outside of the directory where > the Makefile resides. > > Perhaps the ability to use this successfully depends on the implementation > of the VPATH and target resolution support in the make program (and possibly > make program version) that your project is specifically targeting. > > I can not imagine 'make dist' or 'make distcheck' working properly if source > files are not subordinate to the directory containing Makefile. How is 'tar' > supposed to work? I think we must distinguish between a toplevel-Makefile.am and 'sub'-Makefile.am. 'sub' may be a recusive Makefile.am in the same 'configure.ac' project, or in a sub-'configure.ac' project. And referencing source files outside of a sub-Makefile.am's tree but inside a the toplevel-Makefile.am's tree should than also let 'make dist' work, shouldn't it? > > Harlan's posting here was due to Automake not working as he expected for > files which are not in a subdirectory so maybe it does not work. Harlan, is your A/Makefile.am a sub-Makefile.am from a toplevel-Makefile.am, and thus all source files subordinate from this toplevel-Makefile.am?
Re: converting to subdir-objects
On Sun, Mar 8, 2015 at 4:22 PM, Bob Friesenhahn wrote: > On Sun, 8 Mar 2015, Harlan Stenn wrote: >> >> >> The problem I'm seeing (with at least automake-1.12.1 and automake-1.15) >> is that the .deps directories are not being created along the subdir >> path, so the build is failing. >> >> So if A/Makefile.am contains: >> >> foo_SRCS = ... $(srcdir)/../foo/bar.c > > > As far as I am aware, it is wise/required that source paths be subordinate > to the Makefile.am location (no .. bits). If that would really be a requirement now or with subdir-objects, I would say its a regression. Bert
Re: GNU Automake 1.14 released
Hi, On Fri, Jun 21, 2013 at 2:01 PM, Stefano Lattarini wrote: > We are pleased to announce the GNU Automake 1.14 minor release. > > > - The next major Automake version (2.0) will unconditionally activate > the 'subdir-objects' option. In order to smooth out the transition, > we now give a warning (in the category 'unsupported') whenever a > source file is present in a subdirectory but the 'subdir-object' is > not enabled. For example, the following usage will trigger such a > warning: > > bin_PROGRAMS = sub/foo > sub_foo_SOURCES = sub/main.c sub/bar.c > we don't understand how this warning should 'smooth' the transition to post-1.14 in our project. Here is our situation: We have a source file which needs to be compiled twice. But with different compilers. Thus we can't use per-target flags and we use two separate Makefile.am files for this. Because the compilation rules are nearly identical, we use a Makefile.common.inc.am file which will be included by both Makefile.am's. Here is the directory layout (the complete reduced testcase is attached): src/foo.c src/Makefile.am src/Makefile.common.inc.am src/second/Makefile.am The src/Makefile.am looks like: 8< src/Makefile.am 8< --- SUBDIRS = second MY_SRCDIR=. include Makefile.common.inc.am bin_PROGRAMS=foo foo_SOURCES=$(FOO_COMMONSOURCES) >8 src/Makefile.am >8 --- 8< src/second/Makefile.am 8< --- CC=$(top_srcdir)/bin/wrapper MY_SRCDIR=.. include ../Makefile.common.inc.am bin_PROGRAMS=foo-wrapped foo_wrapped_SOURCES=$(FOO_COMMONSOURCES) >8 src/second/Makefile.am >8 --- 8< src/Makefile.common.inc.am 8< --- FOO_COMMONSOURCES = $(MY_SRCDIR)/foo.c >8 src/Makefile.common.inc.am >8 --- This works with automake 1.13.4 as expected. Now, with automake 1.14 we get the newly introduced warning mentioned above in the release statements. Now enabling subdir-objects is not yet an option for us, because we use variables in the _SOURCES list and bug 13928 [1] hits us. So what would be the best transition in this situation? We don't want to remove the Makefile.common.inc.am to avoid the resulting redundancy in the two Makefile.am files. We also can't use the newly introduced %reldir%, because it also throws the warning, and also want to maintain compatibly with pre-1.14 automake. Any guidance is more than welcomed. Kind Regards, Matthias Jurenz & Bert Wesarg [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928 foo-subdir-objects-warnings.tar.gz Description: GNU Zip compressed data
Re: Autoconf caches AC_INIT arguments
Hi, On Wed, May 23, 2012 at 2:17 AM, Bob Friesenhahn wrote: > The forthcoming Automake release is about to break the means I have been > using to automatically version my package (without manually editing > configure.ac) for the past 9 years. I am told to use m4 code in the AC_INIT > arguments in order to supply package versioning information. This is what I > am using: > > AC_INIT(m4_esyscmd([scripts/pkginfo.sh package_name]), > m4_esyscmd([scripts/pkginfo.sh package_version]), > m4_esyscmd([scripts/pkginfo.sh package_bugreport])) > > Unfortunately, this approach works exactly once since Autoconf 2.69 is > caching the computed arguments passed to AC_INIT. Running 'autoconf' or > 'autoreconf' again does not result in an updated configure script. Running > 'autoconf --force' in the source tree seems to work. Thanks for bringing this up. I noticed this problem also some weeks ago, but we still use autoconf 2.68 and automake 1.11.1. I couldn't follow it lately, but the last thing I know was that you can disable the caching via a file named '.autom4te.cfg' besides your configure.ac with the following content: begin-language: "Autoconf" args: --no-cache end-language: "Autoconf" Bert > > Bob
