problem with AM_PATH_PYTHON
Hi. I am having a problem with AM_PATH_PYTHON. I have this in my configure.ac: AS_IF([test x$with_python = xyes], [AM_PATH_PYTHON([2.3], [:], [:]) AX_SWIG_PYTHON AC_CONFIG_FILES([swig/python/Makefile])]) The problem is that when I am cross compiling it ignores the if-block and puts the code of AM_PATH_PYTHON outside. The configure process then breaks like this: configure: WARNING: using cross tools not prefixed with host triplet checking pkg-config is at least version 0.9.0... yes checking for python... /usr/bin/python checking for a version of Python = '2.1.0'... yes checking for the distutils Python package... yes checking for Python include path... -I/usr/include/python2.7 checking for Python library path... -L/usr/lib -lpython2.7 checking for Python site-packages path... /usr/lib/python2.7/dist-packages checking python extra libraries... -lssl -lcrypto -lssl -lcrypto -L/usr/lib -lz -lpthread -ldl -lutil checking python extra linking flags... -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions checking consistency of all components of python development environment... no configure: error: in `/home/wilx/log4cplus-bzr/work-trunk/objdir-mips-linux-gnu': configure: error: Could not link test program to Python. Maybe the main Python library has been installed in some non-standard library path. If so, pass it to configure, via the LDFLAGS environment variable. Example: ./configure LDFLAGS=-L/usr/non-standard-path/python/lib ERROR! You probably have to install the development version of the Python package for your distribution. The exact name of this package varies among them. See `config.log' for more details How can I change the configure.ac to make the Python checks be executed only when my --with-python switch is really enabled. I am not sure if this is a matter for for Automake mailing list or Autoconf list. -- VZ signature.asc Description: OpenPGP digital signature
Re: problem with AM_PATH_PYTHON
On 10/26/2012 07:30 PM, Stefano Lattarini wrote: [Re-adding Václav in CC, please don't drop it in the future] On 10/26/2012 06:47 PM, Robert Boehne wrote: On 10/26/12 09:04, Stefano Lattarini wrote: [SNIP] This doesn't look like output from the Automake-provided AM_PATH_PYTHON macro... That is because it's coming from this line in AX_SWIG_PYTHON in the autoconf-archive. AC_REQUIRE([AX_PYTHON_DEVEL]) I can confirm this is the root of the evil. Inlining the macro without the AC_REQUIRE() makes it work for me in both native and cross compilation cases. Thank you for spotting this! Ah, that makes sense. Thanks for the explanation. So this is neither an autoconf nor an automake problem in the end, but an autoconf-archive one. Indeed. Václav, you should probably find out which project/person is the author of the AX_PYTHON_DEVEL and/or AX_SWIG_PYTHON macros, and report the issue to them. Will do. Thank you for the support, both of you. -- VZ signature.asc Description: OpenPGP digital signature
Re: libtool libraries, dependencies and parallel builds
On 1 November 2012 17:42, Diego Elio Pettenò wrote: On 01/11/2012 09:18, Vincent Torri wrote: lib_eo_libeo_la_LIBADD = $(top_builddir)/src/lib/eina/libeina.la Don't use $(top_builddir) and it should work just fine. Is there a rationale behind this? I am not saying it is wrong, I just want to better understand how things work. -- VZ
building without $(top_builddir) in LDADD (was Re: libtool libraries, dependencies and parallel builds)
On 11/02/2012 09:43 AM, Stefano Lattarini wrote: On 11/02/2012 09:18 AM, Václav Zeman wrote: On 1 November 2012 17:42, Diego Elio Pettenò wrote: On 01/11/2012 09:18, Vincent Torri wrote: lib_eo_libeo_la_LIBADD = $(top_builddir)/src/lib/eina/libeina.la Don't use $(top_builddir) and it should work just fine. Is there a rationale behind this? I am not saying it is wrong, I just want to better understand how things work. My guess is that, albeit having a rule to build 'lib/eina/libeina.la' -- rule generated by Automake from the lib_LTLIBRARIES = lib/eina/libeina.la lib/eo/libeo.la assignment -- make is not smart enough to recognize that, in this Makefile (where '$(top_builddir)' expands to '..'), '$(top_builddir)/src/lib/eina/libeina.la' points in fact to 'lib/eina/libeina.la'. So, when asked to build '$(top_builddir)/src/lib/eina/libeina.la' as a dependency for 'lib/eo/libeo.la' -- dependency derived from the lib_eo_libeo_la_LIBADD = $(top_builddir)/src/lib/eina/libeina.la assignment -- make doesn't know how to proceed, and bails out. So better to just remove the useless extra '$(top_builddir)/src' indirection. Not only this fixes the error, but is also clearer to human readers IMNSHO. I have tried to change my Makefile.am for a test executable by removing the $(top_builddir). But I am getting errors in libtool invocation: --88888888888-- amber2::wilx:~/log4cplus-bzr/work-trunk/objdir/tests/appender_test make /bin/bash ../../libtool --tag=CXX --mode=link g++ -save-temps -fverbose-asm -march=native -g3 -ggdb -Wall -Wextra -pedantic -Wstrict-aliasing -Wstrict-overflow -Woverloaded-virtual -Wold-style-cast -Wc++0x-compat -Wc++11-compat -Wundef -Wshadow -Wformat -Wsuggest-attribute=noreturn -Wno-variadic-macros -fkeep-inline-functions -fstack-check -fstack-protector -ftrapv -fvisibility=hidden -pthread -o appender_test main.o src/liblog4cplus.la -lrt libtool: link: cannot find the library `src/liblog4cplus.la' or unhandled argument `src/liblog4cplus.la' make: *** [appender_test] Error 1 --88888888888-- The resulting Makefile.am looks (almost, becuse I use include to factor out common stuff for multiple tests) like this: --88888888888-- AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_builddir)/include AM_LDFLAGS=@LOG4CPLUS_PROFILING_LDFLAGS@ AM_CXXFLAGS=@LOG4CPLUS_PROFILING_CXXFLAGS@ VPATH=@srcdir@:@top_builddir@ noinst_PROGRAMS = appender_test appender_test_SOURCES = main.cxx appender_test_LDADD = src/liblog4cplus.la --88888888888-- The VPATH bit is there because I have tried to fix the error using it. How can I make this work as you have suggested without $(top_builddir)? -- VZ signature.asc Description: OpenPGP digital signature
looking for a good example of non-recursive Make using project
Hi. I am looking for a good example of a project with non-recursive Make that is using Automake, that is not trivial. I would like to convert my project, log4cplus, to non-recursive Make style, if it is possible. Any recommendations? -- VZ signature.asc Description: OpenPGP digital signature
Re: looking for a good example of non-recursive Make using project
On 11/17/2012 11:36 AM, Vincent Torri wrote: On Sat, Nov 17, 2012 at 11:13 AM, Václav Zeman vhais...@gmail.com wrote: Hi. I am looking for a good example of a project with non-recursive Make that is using Automake, that is not trivial. I would like to convert my project, log4cplus, to non-recursive Make style, if it is possible. Any recommendations? -- VZ I don't know if it's a good example or not, but it's non trivial and is using non-recusrvice build. As it builds several libraries and binaries, I have separated them in several files that I have called Makefile_Foo.am (they are just included and not managed by automake directly) Maybe I am getting blind or you have forgotten to actually mention what is the example. :) -- VZ signature.asc Description: OpenPGP digital signature
Re: managing headers in source
On 07/20/2013 12:52 PM, Simon Richter wrote: Hi Václav, - src/Makefile.am: Listing headers for dependencies and source files. (http://bazaar.launchpad.net/~log4cplus/log4cplus/trunk/view/head:/src/Makefile.am) You do not need to list the headers as source files as long as they are listed somewhere. The dependencies start out empty before the first build (which does not matter because we need to build anyway) and are updated with the list of headers that were actually used during the build -- these will include your headers. Thanks. I have removed the includes from the source listing and nothing has broken. I am not myself sure why I have done it that way in the first place. -- VZ signature.asc Description: OpenPGP digital signature
trivial typo fix
Hi. I am attaching a trivial typo fix patch. -- VZ missing.diff Description: application/itunes-itlp signature.asc Description: OpenPGP digital signature
Re: only installing shared versions of some libs
On 10 December 2013 09:47, Daniel Pocock wrote: I've recently adapted a project to support DSO plugins/modules The existing project includes normal libraries and binaries. In a normal build, we want to a) build and install the shared and static versions of the normal libraries b) only install the shared versions of the plugins I don't mind whether static versions of the plugins are built (we don't currently use them) but I would prefer that make install does not install them Can anybody comment on the best way to do this? The Makefile.am is linked from here (repro/plugins/example/Makefile.am): http://list.resiprocate.org/archive/resiprocate-commit/msg07875.html This is completely untested suggestion: I am assuming you are using Libtool as well. Given the Libtool[1] and Automake manuals, I think it might be possible to do what you want by modifying libexample_la_CXXFLAGS (or similar appropriate) variable to add Libtool's -shared flag, which, I think, should/could do what you want. [1]: http://www.gnu.org/software/libtool/manual/html_node/Compile-mode.html#Compile-mode [2]: http://www.gnu.org/software/automake/manual/html_node/Libtool-Flags.html -- VZ
Re: Automake 1.14 and subdir-objects
On 14 August 2014 00:56, David Beer db...@adaptivecomputing.com wrote: Gavin, I am going to test out and see if the BUILT_SOURCES option works. Making a single Makefile would not be an option as there are over 500 Makefiles in my project and combining them into one would not be maintainable. I am not sure if log4cplus is the best or even comparable show case, as it is two orders of magnitude smaller than 500 Makefiles, but I will chime in anyway. For log4cplus, I have converted existing multiple Makefiles into a single Makefile by using Make includes. The only problem, I can see in your situation using this solution, is possible namespace pollution. I'm curious though - am I really the only person having this issue? How are people using unit tests with the new version of automake? It would seem that these changes make it very difficult for anyone who has unit tests in their project. On Thu, Jul 31, 2014 at 4:21 PM, Gavin Smith gavinsmith0...@gmail.com wrote: On Thu, Jul 31, 2014 at 9:32 PM, David Beer db...@adaptivecomputing.com wrote: Gavin, Thanks for your reply. Here's a more specific breakdown of what the project does: src/a/Makefile.am: a_SOURCES = bob.c tom.c src/b/Makefile.am: b_SOURCES = mary.c ../a/tom.c The purpose was so that tom.c would be recompiled with a different preprocessor switch. There were only a few files that failed for this case, so I was able to work around this. The other case: It is clearer now what you are trying to do. It might be worth noting that you can specify target-specific compliation flags with variables like a_CPPFLAGS and b_CPPFLAGS: however, this would normally be done when a and b were targets defined in the same Makefile.am. This would lead the created object files to have different names, so might work in your case, but I believe that this kind of sharing of source files between Makefile.am's is not really supported. I imagine there could be problems with e.g. dependency tracking. Maybe consider using a non-recursive build system with a single Makefile.am if it is appropriate for your project. Another idea is to specify the files like tom.c in src/b/Makefile.am as BUILT_SOURCES=tom.c and then have a hand-written rule to copy the tom.c file into the build directory for b, e.g. tom.c: cp $(top_builddir)/a/tom.c . (I haven't tested this.) -- David Beer | Senior Software Engineer Adaptive Computing -- VZ
Re: Macro to select c++ as default compiler for c files.
On 3 November 2014 11:28, Lakshmi M laksh...@tataelxsi.co.in wrote: Hi All, I am working with autotools and i wish to use c++ compiler by default for compiling my c files. USUAL behaviour : ex : myexecutable_SOURCES = file.cpp - uses c++ compiler myexecutable_SOURCES = file.c - uses c compiler (myexecutable_SOURCES is defined in my Makefile.am) Expected behaviour : ex : myexecutable_SOURCES = file.cpp - uses c++ compiler myexecutable_SOURCES = file.c - SHOULD USE c++ compiler (myexecutable_SOURCES is defined in my Makefile.am) I think that Automake simply matches on the file name extension. If you cannot rename the source files to have one of the common C++ source file extensions (.C, .cxx, .c++, .cc) then you will have to supply compiler specific flags, I think, like the GCC's `-x c++`. I tried using AC_PROG_CC([c++]) and AC_LANG([C++]) in my configure.ac but its still using c compiler. Can anyone please let me know how to use c++ compiler as default for compiling my c files. -- VZ
