Re: __pycache__ directories and distcleancheck

On Wed, Jun 13, 2018 at 12:30 PM Jim Meyering wrote: > Thanks for the report. Would you please create a minimal set-up to > demonstrate the problem? That will probably expedite a proper fix. I will, our project can in no way be considered minimal so I'll try and create a very small example. It

__pycache__ directories and distcleancheck

Hi We've recently updated our code to support Python3 and are running into a problem with __pycache__ directories being leftover in the build directory after a distclean. Is the appropriate thing to do here simply to list the files in DISTCLEANFILES or is there a better way? Cheers Adam

Re: automake-1.16: aclocal is unable to process AM_PATH_PYTHON with variable as value

On Tue, Feb 27, 2018 at 9:07 PM, Adam Mercer <ramer...@gmail.com> wrote: >>> /usr/bin/m4:configure.ac:506: bad expression in eval (bad input): ($+1) != >>> (2) >>> /usr/bin/m4:configure.ac:506: bad expression in eval (bad input): >>> (0r36:PYTHON_+

Re: automake-1.16: aclocal is unable to process AM_PATH_PYTHON with variable as value

On Mon, Feb 26, 2018 at 12:28 PM, Thomas Deutschmann wrote: > Hi, > > with automake-1.16, code like > >> AM_PATH_PYTHON([$PYTHON_VERSION]) > > or > >> AM_PATH_PYTHON([$PYTHON_MIN_VERSION]) > > as found in > >

use /var/tmp for distcheck installation test

Hi One machine I use for testing has /tmp as a tmpfs filesystem and the distcheck process is failing during the install check as the /tmp filesystem is not big enough. Is there a way to get distcheck to use another temporary filesystem for testing, such as /var/tmp? Cheers Adam

Re: use /var/tmp for distcheck installation test

On Tue, Aug 12, 2014 at 4:36 PM, Nick Bowler nbow...@elliptictech.com wrote: Setting TMPDIR environment variable might help. And indeed it does, thanks. Cheers Adam

Setting python interpreter in scripts

Hi In one of our projects we have several python scripts that we need to ensure that the python interpreter is set to the one found by configure. At the moment we are doing this by having the interpreter set to @PYTHONPROG@ and then using the following rule: python_config.sed: @-rm -f

Re: source file in different directory to Makefile and subdir-objects

On Fri, Jul 19, 2013 at 7:01 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: But consider that the behaviour currently enabled by 'subdir-objects' option will be made the default one and *the only aviailable one* in Automake 2.0, so you might want to start drawing a roadmap to change

source file in different directory to Makefile and subdir-objects

Hi Since updating to automake-1.14 I'm getting warnings of the form: src/inspiral/posterior/mpi/Makefile.am:14: warning: source file '$(srcdir)/../LALInferenceMCMC.c' is in a subdirectory, src/inspiral/posterior/mpi/Makefile.am:14: but option 'subdir-objects' is disabled automake: warning:

Re: files left in build directory after distclean

On Tue, May 29, 2012 at 7:11 PM, Peter Johansson troj...@gmail.com wrote: To have files with same name in both builddir and srcdir is to ask for problems, IMHO. What happens if srcdir and builddir are the same? If you wanna generate $(builddir)/git_version.sed, don't distribute it as well.

Re: files left in build directory after distclean

On Wed, May 23, 2012 at 6:13 PM, Peter Johansson troj...@gmail.com wrote: For me distcheck complains about no sed file which is because you call it 'sed -f git_version.sed' while it should be 'sed -f $(srcdir)/git_version.sed' as the sed script is distributed (in srcdir). But the script

Re: files left in build directory after distclean

On Wed, May 23, 2012 at 9:03 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: Is 'git_version.sed' intended to be distributed?  If yes, you must place it in EXTRA_DIST (and you have an usage error in that you've not done so). Of course! Thanks, I imagined it'd be due to something

Re: files left in build directory after distclean

On Tue, May 22, 2012 at 12:06 PM, Nick Bowler nbow...@elliptictech.com wrote: Probably all you need to do is add these generated files to CLEANFILES, e.g.,  CLEANFILES = git_version.py git_version.sed so that make clean deletes them. I'd thought of that, but what puzzles me (and the reason

Re: files left in build directory after distclean

On Tue, May 22, 2012 at 2:30 PM, Nick Bowler nbow...@elliptictech.com wrote: Since you listed the LALAppsVCSInfo.h file in lalapps_version_SOURCES variable, that header got included in your distribution tarball.  It therefore was not generated at all during the build done by distcheck, so

Re: files left in build directory after distclean

On Tue, May 22, 2012 at 12:06 PM, Nick Bowler nbow...@elliptictech.com wrote: Probably all you need to do is add these generated files to CLEANFILES, e.g.,  CLEANFILES = git_version.py git_version.sed so that make clean deletes them. Actually thinking about this in more detail,

Re: specifying _LDADD and _CFLAGS for test codes

On Wed, May 9, 2012 at 5:13 AM, Stefano Lattarini stefano.lattar...@gmail.com wrote: s/PTHEAD/PTHREAD/ here ;-) Let me know if the problem is solved by that. Thanks, I knew it would be something stupid but I was hoping it wouldn't be that stupid! Cheers Adam

CC $sourcebasename-$sourcebasename.o displayed during silent rules build

Hi Next, hopefully not so stupid, question; my Makefile.am is now AM_CFLAGS = $(LALSUPPORT_CFLAGS) LDADD = $(LALSUPPORT_LIBS) $(top_builddir)/src/liblalframe.la if PTHREAD PTHREADPRGS = \ TestLowLatencyData1 \ TestLowLatencyData2 \ TestLowLatencyData3 endif if

Re: CC $sourcebasename-$sourcebasename.o displayed during silent rules build

On Wed, May 9, 2012 at 12:09 PM, Stefano Lattarini stefano.lattar...@gmail.com wrote: This is expected, since the use of per-target compilation flags causes the generated object files to be renamed; see: http://www.gnu.org/software/automake/manual/automake.html#Renamed-Objects Good, I was

specifying _LDADD and _CFLAGS for test codes

Hi I have some test codes that require pthread so inorder to ensure that the appropriate flags are added to the build I have the following in my Makefile.am if PTHREAD PTHREADPRGS = \ TestLowLatencyData1 \ TestLowLatencyData2 \ TestLowLatencyData3 endif if LALSUPPORT

lex-depend-cxx automake-1.12 test failure on Mac OS X 10.7.3 (Xcode-4.3.2)

Hi I've been looking at getting the version of automake in MacPorts updated to automake-1.12 and I'm getting the following test failure: FAIL: t/lex-depend-cxx == Running from installcheck: no Using TAP: no PATH =

Re: Automake 1.11.1b test release

On Sat, Dec 10, 2011 at 13:03, Stefano Lattarini stefano.lattar...@gmail.com wrote: Please report bugs and problems to bug-autom...@gnu.org, and send general comments and feedback to automake@gnu.org. On Mac OS X 10.7 (Lion) All 826 tests behaved as expected (11 expected failures) Cheers

Removing Mac OS X resource forks from distribution tarballs

Hi When I build distribution tarballs on my Mac sometimes resource forks find their way into the tarball and then when they are extracted on another platform, Debian for example, these resource forks show up as separate files of the for ._*, e.g.: ldg-cert-util-2.5/debian# ls -la total 68

Re: Removing Mac OS X resource forks from distribution tarballs

On Wed, Mar 30, 2011 at 11:46, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Ralf Is there some rule that I can add that will strip any resource forks from files before adding them to the distribution? dist-hook: remove-mac-resource-forks remove-mac-resource-forks:        rm -f

selectively building with mpi

Hi In one of our projects we have one code that can be built using ${MPICC} (if it is available), but not other codes. How can I specify to use ${MPICC} for one code, but ${CC} for the others. Also if ${MPICC} is not found, by AX_MPI, the code can fall back to be built using ${CC}? So I guess

Re: selectively building with mpi

On Mon, Oct 4, 2010 at 12:00, Brian J. Murrell brian.murr...@oracle.com wrote: Check the archives on this. Will do. I had a very brief look but couldn't find much, I'll have a more detailed look. In one of our projects we have one code that can be built using ${MPICC} (if it is available),

Re: Build rules for CUDA source files

On Thu, Sep 9, 2010 at 15:55, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Showing the line before this would have been interesting. I'm doing all this testing on Debian Lenny, which has libtool-1.5.29. I don't really want to upgrade libtool unless I really have to. Yes.  You add -Xcompiler

Build rules for CUDA source files

Hi I'm working on adding some code that uses the NVidia CUDA compiler and libraries to one of our projects. I believe that I have added the appropriate rules to Makefile.am to specify how to do the build: noinst_LTLIBRARIES = libfft.la libfft_la_SOURCES = \ TimeFreqFFT.c \ AverageSpectrum.c

Re: Build rules for CUDA source files

On Thu, Sep 9, 2010 at 15:27, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Ralf pkginclude_HEADERS = \   ComplexFFT.h \   RealFFT.h \   FFTWMutex.h \   TimeFreqFFT.h \   CudaPlan.h JFTR, headers not going to be installed can be listed in *_SOURCES as well. I know, we need all the

appending to BUILT_SOURCES, if appropriate

Hi For one of the projects I work on we need to add something like the following to each Makefile.am to ensure that vcs information is current: vcsID: cd $(top_builddir)/src/lalapps $(MAKE) liblalapps.la BUILT_SOURCES = vcsID As this is going to be the same in each Makefile.am, I would like

Re: appending to BUILT_SOURCES, if appropriate

On Thu, Mar 11, 2010 at 14:42, Eric Blake ebl...@redhat.com wrote: How about modifying the makefiles that don't append to BUILT_SOURCES to just add the line BUILT_SOURCES= prior to the include, then use BUILT_SOURCES+= in the included file. Of course, great idea! Thanks! Cheers Adam

Re: test/Makefile.am: required file `gnuscripts/compile' not found

On Wed, Dec 30, 2009 at 21:37, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: Ralf The rules generated by Automake may or may not need to use the -c and -o options at the same time.  This depends upon a few internal details: whether the subdir-objects option is used, whether objects need to be

Re: test/Makefile.am: required file `gnuscripts/compile' not found

On Wed, Dec 30, 2009 at 21:59, Adam Mercer ramer...@gmail.com wrote: Note that for library dependencies that apply to all programs in a makefile you can use the global LDADD variable, which may allow you to remove most if not all of those per-target *_LDADD settings. That's something I've

Re: test/Makefile.am: required file `gnuscripts/compile' not found

On Wed, Dec 30, 2009 at 22:17, Adam Mercer ramer...@gmail.com wrote: Just made this change and autoreconf no longer complains if compile isn't available. Thanks! And it's started complaining again :-( I've tried running automake manually, with the verbose option: automake: reading test

only running tests if a given library is available

Hi In one of my projects the test suite requires an extra library to be available that isn't required to build the rest of the package so I would like to make this library an optional dependency and then only build the test suite if configure finds this library. To detect this library I have the

Re: only running tests if a given library is available

On Wed, Aug 12, 2009 at 12:28, Peter Johanssontroj...@gmail.com wrote: Peter Which programs are built during `make check' is determined by `check_PROGRAMS' and not by `TESTS'. How is check_PROGRAMS defined in your Makefile.am? Of course, thanks wrapping check_PROGRAMS with the appropriate

Re: Circular dependency dropped warning from make in relating to CUDA code

On Sat, Jun 27, 2009 at 05:33, Ralf Wildenhuesralf.wildenh...@gmx.de wrote: Ralf Why not name the product file CudaChisq.c rather than CudaChisq.cu.c? The problem here is that the other half of the circle comes from the make-internal rule `%: %.c' for compiling single-source programs. I

Re: Circular dependency dropped warning from make in relating to CUDA code

On Mon, Jun 29, 2009 at 20:29, Ralf Wildenhuesralf.wildenh...@gmx.de wrote: Using $ in inference rules, as in my example, is portable. In target rules, you can spell out the input file name (including an eventual vpath prefix). Thanks for the clarification. Cheers Adam

Circular dependency dropped warning from make in relating to CUDA code

Hi I'm in the middle of integrating some CUDA code, for utilising GPUs, into one of our projects and seeing the following warning returned from make: make: Circular CudaChisq.cu - CudaChisq.cu.c dependency dropped. The following rule is used to generate the .c file from the .cu source:

Re: rebuilding following a change in prefix?

On Thu, May 7, 2009 at 23:52, Jan Engelhardt jeng...@medozas.de wrote: Well, automake (unfortunately?) does not currently issue a recompile when the compiler command changed. It would be really cool to have that, though. Thanks, I was worrying I'd done something wrong in my setup. Cheers

Re: Linking problem when built in parallel

On Tue, May 5, 2009 at 00:48, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: I assume the Makefile.am you posted is in the lib subdirectory, right? Yes it is. If yes, then change this lal_version_LDADD = $(top_builddir)/lib/liblal.la to this:  lal_version_LDADD = liblal.la as 'make' is