Re: Automake 1.11.1b test release

On Sat, Dec 10, 2011 at 13:03, Stefano Lattarini wrote: > Please report bugs and problems to , and send > general comments and feedback to . On Mac OS X 10.7 (Lion) All 826 tests behaved as expected (11 expected failures) Cheers Adam

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 = /opt/local/var/macports/build/_Users_ram_macports_ports_devel

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 chec

Re: specifying _LDADD and _CFLAGS for test codes

On Wed, May 9, 2012 at 5:13 AM, Stefano Lattarini 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 LALSUPPORT

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

On Wed, May 9, 2012 at 12:09 PM, Stefano Lattarini wrote: > This is expected, since the use of per-target compilation flags causes > the generated object files to be renamed; see: > Good, I was worried that I was doing s

files left in build directory after distclean

Hi For one of my projects I'm running into an error where distcheck fails with the error: ERROR: files left in build directory after distclean: ./lalapps/src/lalapps/git_version.py ./lalapps/src/lalapps/git_version.sed Why are these files remaining and how should I ensure they are removed correc

Re: files left in build directory after distclean

On Tue, May 22, 2012 at 12:06 PM, Nick Bowler 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 I didn't use it)

Re: files left in build directory after distclean

On Tue, May 22, 2012 at 2:30 PM, Nick Bowler 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 nothing needed to be cle

Re: files left in build directory after distclean

On Tue, May 22, 2012 at 12:06 PM, Nick Bowler 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, git_version.py should not be

Re: files left in build directory after distclean

On Wed, May 23, 2012 at 9:03 AM, Stefano Lattarini 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 trivial like that. Cheers Ada

Re: files left in build directory after distclean

On Wed, May 23, 2012 at 6:13 PM, Peter Johansson 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 copies git_version.s

Re: files left in build directory after distclean

On Tue, May 29, 2012 at 7:11 PM, Peter Johansson 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. Or distribute

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: possib

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

On Fri, Jul 19, 2013 at 7:01 PM, Stefano Lattarini 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 > the assumptions done by

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 python_co

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 wrote: > Setting TMPDIR environment variable might help. And indeed it does, thanks. Cheers Adam

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 > > https://gitlab.com/cryptsetup/cryptsetup/blob/master/configure.ac#L506 > https://github.c

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 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_+1) != (0*4) >>> autom

__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: __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

Linking problem when built in parallel

Hi I've inherited the maintenance of a library at work and there is currently a linking problem when the library is built in parallel, i.e. the -j option is passed to make, it builds find when the -j option is not specified. It fails with the following error: $ make -j2 /bin/sh ../libtool --tag=

Re: Linking problem when built in parallel

On Tue, May 5, 2009 at 00:48, Ralf Wildenhues 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 not smart e

rebuilding following a change in prefix?

Hi I have noticed some strange behaviour with the build system on a project I am working on, consider the following: $ ./configure --prefix=/path/1 $ make $ make install $ ./configure --prefix=/path/2 $ make $ make install I would expect the make after the second configure to rebuild all the sou

Re: rebuilding following a change in prefix?

On Thu, May 7, 2009 at 23:52, Jan Engelhardt 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 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: CudaChi

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

On Sat, Jun 27, 2009 at 05:33, Ralf Wildenhues 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 guess you can also avoi

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

On Mon, Jun 29, 2009 at 20:29, Ralf Wildenhues 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

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 f

Re: only running tests if a given library is available

On Wed, Aug 12, 2009 at 12:28, Peter Johansson 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 if/endif does the

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

Hi On one of my projects I'm running into an issue, only on certain platforms, where the compile script isn't available. e.g. on CentOS 5 $ autoreconf test/Makefile.am: required file `gnuscripts/compile' not found autoreconf: automake failed with exit status: 1 $ yet I have other projects, on th

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

On Wed, Dec 30, 2009 at 21:37, Ralf Wildenhues 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 > renamed due to pe

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

On Wed, Dec 30, 2009 at 21:59, Adam Mercer 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. &g

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

On Wed, Dec 30, 2009 at 22:17, Adam Mercer 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

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 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

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 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 headers inst

Re: Build rules for CUDA source files

On Thu, Sep 9, 2010 at 15:55, Ralf Wildenhues 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 -fPIC to compile flag

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 I'm

Re: selectively building with mpi

On Mon, Oct 4, 2010 at 12:00, Brian J. Murrell 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), but not other codes.

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 drwxr-x

Re: Removing Mac OS X resource forks from distribution tarballs

On Wed, Mar 30, 2011 at 11:46, Ralf Wildenhues 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 $(DISTDIR)/._* > > ?  I'm