Re: Producing MS Developer Studio Project files

Hi Benoit, Benoit SIGOURE wrote: [1] http://www.tsunanet.net/~tsuna/cccl [2] http://www.tsunanet.net/~tsuna/make-3.81-cygwin.patch http://www.tsunanet.net/~tsuna/make-3.81-cygwin_MAKE_expansion.patch Can't be bothered to find the related posts on GNU Make W32 ML archive, sorry. It

Re: 'toolman_MANS' not supported?

Hi Ralf, Ralf Wildenhues wrote: Hello Harald, * Harald Dunkel wrote on Mon, Apr 30, 2007 at 01:04:25PM CEST: I have to install several manpages in separate subdirectories. But it seems that something like toolmandir = ${prefix}/tooldir/man toolman_MANS = hello.1 does

'toolman_MANS' not supported?

Hi folks, I have to install several manpages in separate subdirectories. But it seems that something like toolmandir = ${prefix}/tooldir/man toolman_MANS = hello.1 does not work. Did I miss something in the documentation here? (I am using Automake 1.9.6.) Regards Harri

depcomp supporting MSVC's --showIncludes?

Hi folks, Does anybody know a patch for depcomp to support the -showIncludes flag of Microsoft's recent compiler? Regards Harri

Re: using VPATH in depend2.am?

? Regards Harri === Stepan Kasal wrote: Hello, On Fri, Oct 21, 2005 at 10:58:44PM +0200, Harald Dunkel wrote: Stepan Kasal wrote: `IFS=:; x=':$(VPATH)'; \ for d in $$x; do \ test -n $$d d=$$d/; \ test -f

question about DEFAULT_INCLUDES and -I.

Hi folks, it seems that DEFAULT_INCLUDES is set deeply within automake.pl to DEFAULT_INCLUDES = -I. -I$(srcdir) What is the reasoning here? Doesn't this undermine the difference between #include myheader.h and #include myheader.h ? Regards Harri

Re: question about DEFAULT_INCLUDES and -I.

Hi Ralf, Ralf Wildenhues wrote: Hi Harald, * Harald Dunkel wrote on Wed, Apr 26, 2006 at 10:44:55AM CEST: it seems that DEFAULT_INCLUDES is set deeply within automake.pl to DEFAULT_INCLUDES = -I. -I$(srcdir) Only if not using the Automake option `nostdinc'. I did not see

Re: autotools support for msvc

Hi Peter, Peter Ekberg wrote: Here's my current diff from libtool cvs head. I have been buried in work lately so I have not tested it in a while. Use at your own risk and all that... Many thanx. Harri

Re: useful bug reports

Hi Ralf, Ralf Wildenhues wrote: Erm. Before continuing on this road any further: have you tried using cccl? It's a wrapper script for MSVC designed to do exactly what looks like quite a bit of work inside the autotools. I'm not saying it can't be done, or should not be done, but it has

Re: useful bug reports

PS: Sorry, I pasted the wrong Makefile.am into the EMail, see below. Harald Dunkel wrote: Hi Ralf, Ralf Wildenhues wrote: Harald, please consider *providing more and useful information* if you want help. I for one can't read your mind, and almost every first post of yours leaves me wanting

[Patch] Re: compile not copied? Why?

Hi folks, Harald Dunkel wrote: Hi folks, What is the criteria for copying the compile script into the source directory tree? I have some *.cc code, it is mentioned in my Makefile.am file, configure detects that the compile script must be used, too, but Automake doesn't provide

Re: [Patch] Re: compile not copied? Why?

Ralf Wildenhues wrote: Hi Harald, Please consider this thread: http://lists.gnu.org/archive/html/libtool/2005-10/msg00069.html How is this thread related to copying a missing script? Please note that C support is broken, too, as soon as there is some C++ code in your Makefile.am.

Re: building 32bit and 64bit libs with the same name

Hi Ralf, Ralf Corsepius wrote: On Tue, 2005-11-08 at 08:15 +0100, Harald Dunkel wrote: Hi folks, I would like to build 32bit and 64bit libraries within the same Makefile.am. In the install directory tree the libs should get the same name, but the 64bit library is supposed to be installed

compile not copied? Why?

Hi folks, What is the criteria for copying the compile script into the source directory tree? I have some *.cc code, it is mentioned in my Makefile.am file, configure detects that the compile script must be used, too, but Automake doesn't provide it. ??? Any help would be highly appreciated.

building 32bit and 64bit libs with the same name

Hi folks, I would like to build 32bit and 64bit libraries within the same Makefile.am. In the install directory tree the libs should get the same name, but the 64bit library is supposed to be installed in ${exec_prefix}/lib64, of course. Obviously automake can't distinguish libraries in the

Re: AC_PROG_CC_C_O doesn't work with VC++

Hi folks, Stepan Kasal wrote: I committed the patch attached to this mail. Could you please apply the attached patch as well? It is necessary on Windows to detect '\' as a directory path separator. Many thanx Harri --- compile~ 2005-10-24 12:03:48.0 +0200 +++ compile 2005-10-26

Re: compile with VC++

Stepan Kasal wrote: I looked at /usr/share/automake-1.9/compile and I cannot understand how this could happen. I think that the parametr to compile should look like some/path/main.c which becomes cfile, and then cofile is assigned as cofile=`echo $cfile | sed -e 's|^.*/||' -e

Re: compile with VC++

Hi Stepan, Stepan Kasal wrote: I looked at /usr/share/automake-1.9/compile and I cannot understand how this could happen. I think that the parametr to compile should look like some/path/main.c which becomes cfile, and then cofile is assigned as cofile=`echo $cfile | sed -e

Re: using VPATH in depend2.am?

Hi, Stepan Kasal wrote: Hello, Suggested code for today: ;-) `IFS=:; v=$(VPATH); \ for d in '' $$v; do \ test -n $$d d=$$d/; \ test -f $${d}%SOURCE% echo $$d break; \ done`%SOURCE% Works for me, as it seems. Regards Harri

Re: using VPATH in depend2.am?

Hi Stepan, Stepan Kasal wrote: So I suppose something like this `IFS=:; for d in '' '$(srcdir)' $(VPATH); do \ test -n $$d d=$$d/; \ test -f $$d%SOURCE% echo $$d break; \ done`%SOURCE% Could you test whether this works for you? Something

Re: using VPATH in depend2.am?

Stepan Kasal wrote: Your proposal looks good, except I think it might be better to use single quotes around $(VPATH). And the quoting around $d, which I introduced, is redundant. That yields: `IFS=:; x=':$(VPATH)'; \ for d in $$x; do \ test -n $$d d=$$d/; \

Re: using VPATH in depend2.am?

Hi folks, Ralf Wildenhues wrote: What exactly does not work for you? I tried to use VPATH = $(srcdir):$(top_srcdir)/some/common/dir in Makefile.am. In what circumstances? I am not sure what you mean by circumstances. I am trying to build a C++ library (no libtool) using both

using VPATH in depend2.am?

Hi folks, Would it be possible to rely upon $(VPATH) in depend2.am? Instead of `test -f '%SOURCE%' || echo '$(srcdir)/'`%SOURCE% something like this could work, too (not verified yet): `test -f '%SOURCE%' || (VPATH=$(VPATH); test $$VPATH || VPATH=$(srcdir); for i in \`IFS=:;

question about installing libraries

Hi folks, AFAICS libraries are installed using ${INSTALL_DATA}. Wouldn't it be more consequent to use ${INSTALL_PROGRAMS} here? Both libraries and programs is something that could be stripped, i.e. you could use 'install -s'. But defining INSTALL_DATA to use 'install -s' doesn't work, of course.

Re: creating the $(SUBDIRS) at runtime?

Simon Richter wrote: Hi, Harald Dunkel wrote: I would like to create the directories for some $SUBDIRS as needed at runtime, e.g. erm, why? Unfortunately Automake complains about the missing directories in the source tree. Yes, because the structure of the source tree

creating the $(SUBDIRS) at runtime?

Hi folks, I would like to create the directories for some $SUBDIRS as needed at runtime, e.g. : SUBDIRS = mydir mydir/Makefile: FORCE ${INSTALL} -d mydir generate $@ : Unfortunately Automake complains about the missing directories

Re: Force -O0 flags, inhibit the default -O2 flags

Sander Niemeijer wrote: On woensdag, sep 28, 2005, at 17:04 Europe/Amsterdam, Harald Dunkel wrote: autoconf sets CFLAGS/CXXFLAGS to reasonable defaults, that's all. If these defaults cause problems on your platforms, you have to override them. They cannot be called defaults, if they get

Re: Force -O0 flags, inhibit the default -O2 flags

Ralf Corsepius wrote: On Tue, 2005-09-27 at 12:53 +0200, Harald Dunkel wrote: Ralf Corsepius wrote: Nope. You don't seem to have understood how things are working: AM_CFLAGS/AM_CXXFLAGS are supposed to take flags having been specified by a package's developer. Understood. CFLAGS/CXXFLAGS

Re: Force -O0 flags, inhibit the default -O2 flags

Ralf Corsepius wrote: Nope. You don't seem to have understood how things are working: AM_CFLAGS/AM_CXXFLAGS are supposed to take flags having been specified by a package's developer. Understood. CFLAGS/CXXFLAGS are suppoed to take flags having been specified by a package's installer.

Re: Force -O0 flags, inhibit the default -O2 flags

Brian wrote: I have a need to force three files to not be optimized. I've followed the instructions in the manual for setting them up in their own library, and then using LIBADD to combine it with the original library. If I use AM_CXXFLAGS, the -O0 is superceded by a -O2. The same occurs if

Re: *_DATA primaries tried twice during make install?

Stepan Kasal wrote: ad 1) The install-am - all-am dependency causes everuthing to be checked. ad 2) I see the fillowing dependencies in a Makefile.in: install-exec-am: install-binPROGRAMS install-libLTLIBRARIES install-binPROGRAMS: $(bin_PROGRAMS) install-libLTLIBRARIES:

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

Bob Proulx wrote: Harald Dunkel wrote: Question about make depend: If I set SRCDIR = ../src noinst_PROGRAMS = hello hello_SOURCES = ${SRCDIR}/hello.c Shouldn't you be using normal VPATH? That is, you are setting hello_SOURCES = ../src/hello.c. But I don't think you

Re: make depend problem with hello_SOURCES = ${SRCDIR}/hello.c

Hi Ralf, Ralf Wildenhues wrote: How about using either - a convenience archive, or - one single large Makefile.am with subdir-objects (see info Automake Alternative) A convenience library doesn't work, because I have pretty many different CPP defines, probably set either in configure,

why does make install depend upon all?

Hi folks, Please see subject. Of course I would agree that this dependency is usually a good thing, but sometimes it might be helpfull to do a 'make install' for another prefix e.g. in your stow directory without verifying all the dependencies again. It would be easy to split the old install

make install-strip

Hi folks, Would it be possible to strip libraries at install time? Or do I have to set CFLAGS/CXXFLAGS? Regards Harri

Re: how to extend the Makefile templates?

Hi Ralf, Ralf Wildenhues wrote: Hi Harald, * Harald Dunkel wrote on Tue, Aug 16, 2005 at 12:39:46PM CEST: I would need some way to add recursive targets to all generated Makefiles, without asking every owner of every Makefile.am to append some include statement or some keyword

Re: how to extend the Makefile templates?

Ralf Wildenhues wrote: This would assume that I am allowed to change the foreign Makefile.am files, Yes. What prevents this? The version control system, maybe? Code coming from another business units that I have to use as is? Or simply because it is read-only? and it assumes that

how to extend the Makefile templates?

Hi folks, I would need some way to add recursive targets to all generated Makefiles, without asking every owner of every Makefile.am to append some include statement or some keyword to be replaced by AC_SUBST_FILE. What would be your suggestion to solve this? Regards Harri

EH: some warning message, please?

Hi folks, Would it be possible to tell Automake to print some warning message for this bad Makefile.am: bin_PROGRAMS += PreciousUtils_checker PreciousUtils_checker_SOURCES = precious/Utils/unittest/src/SLListTest.cc \ precious/Utils/unittest/src/DLListTest.cc \

Re: how to run a test file with command line options...

Ed Hartnett wrote: Howdy all! If I have some tests, and want to run them with command line options, how do I do it? For example, I have to have a shell script to run tst_parallel below, because it needs to be called with the poe command, and some env vars set. In other cases, I need to

Re: How to extend automake?

Bruno Haible wrote: Harald Dunkel wrote: It would be pretty cool if Automake could append this automagically when generating the Makefile.in files. How could it know to which Makefile.ins it should append it? There are typically several Makefile.ams for one configure.ac. I just would

Re: How to extend automake?

Tom Howard wrote: Hi Bruno, I used ax_add_mk_macro in ax_dist_rpm.m4 so that in my projects I can run make dist-rpm to create an rpm distribution. Using these macros, all I have to add to the Makefile.am is @INCLUDE_MK@ at the end. It would be pretty cool if Automake could append

Re: BUILT_SOURCES too clumsy

In the meantime I have patched automake, e.g. diff -ur automake-1.9.5/lib/am/library.am automake-1.9.5.new/lib/am/library.am --- automake-1.9.5/lib/am/library.am2003-06-02 09:08:40.0 +0200 +++ automake-1.9.5.new/lib/am/library.am 2005-05-22 20:22:51.0 +0200 @@ -15,6 +15,7 @@

BUILT_SOURCES too clumsy

Hi folks, The targets in BUILT_SOURCES are unconditionally built for 'make all' and 'make install' and 'make check'. Very clumsy. I would like to generate some code for an optional convenience library exactly when needed. Would there be a way to introduce a derived variable libmylib_a_PREDEPEND,

Re: Automake and makedepend

Stan Guillory wrote: 2) Is there a way to force automake to set the depmode to makedepend? What happens if you run make CCDEPMODE=depmode=makedepend CXXDEPMODE=depmode=makedepend ? If it works as expected, then you might add a test for the compiler version to your configure.ac, and

Re: abs_top_builddir not working?

Stepan Kasal wrote: Hello, On Mon, May 09, 2005 at 06:02:24PM +0200, Harald Dunkel wrote: I tried to replace $(top_builddir) in a Makefile.am by $(abs_top_builddir), but the new Makefile did not define this macro. Actually, this is a bug/feature of Automake, that these variables

why removing configure substitutions for myprog_DEPENDENCIES?

Hi folks, I have a question about how the *_DEPENDENCIES are computed from *_LDADD: If I write a Makefile.am bin_PROGRAMS = myprog MYLIB = liba.a myprog_LDADD = \ $(MYLIB) \ libb.a \ -Lsomepath \ -lother

Re: why removing configure substitutions for myprog_DEPENDENCIES?

Stepan Kasal wrote: Hello, On Tue, Apr 19, 2005 at 02:50:03PM +0200, Harald Dunkel wrote: Why are the configure substitutions removed? because they are not known at the time when automake runs. Understood. Would it be possible to compute myprog_DEPENDENCIES at make's runtime instead

Re: 'make clean' is removing too many files

Warren Young wrote: Harald Dunkel wrote: If I add something like lib_LIBRARIES = /some/static/old/lib2install.a ...then you're probably doing something wrong. That should probably go in LDADD. No, LDADD does not help. I have some 3rd party libraries to include into the install

'make clean' is removing too many files

Hi folks, If I add something like lib_LIBRARIES = /some/static/old/lib2install.a to my Makefile.am, then the generated Makefile includes /some/static/old/lib2install.a in the list of files to remove for the clean target. This is certainly not correct. Only targets that are built by this

Re: Easy way to have a make target that omits some files?

Ralf Wildenhues wrote: Stab in the dark: Idea 1) Put only everything to be installed both times in bin_PROGRAMS etc, the other stuff in noinst_PROGRAMS etc. Use install-data-local and install-exec-local for installing the extra stuff within `make install', but only if some variable,

Re: builddir vs. srcdir

Stepan Kasal wrote: Hello, On Tue, Mar 08, 2005 at 11:56:56PM +0200, Paul Pogonyshev wrote: foo.c foo.h : $(srcdir)/foo.list $(PARSE_LIST) $(PARSE_LIST) $(srcdir)/foo.list foo.h foo.c\ || (rm -f foo.c foo.h ; exit 1) This rule can break with parallel make. You can solve the