Re: QT Plugins, target build order AND BUILT_SOURCES

Hello all, the only idea at this time is to add another subproject and put the special test forms in there... I must copy some other source files or use in XXX_SOURCES = ../src/files.cpp (ugly??) The build order can modified via SUBDIRS in the toplevel Makefile.am... Greetings andre Am

QT Plugins, target build order AND BUILT_SOURCES

Hello all, I've a litte problem to build subproject correctly... In my Makefile.am are one "bin_programs" and one "lib_LTLIBRARIES". The plugin is a shared linked library, so that it can loaded into QT's designer. The program should test all plugin widgets, featu

Re: "make dist" and "make distcheck" trouble

On 9/28/2009 7:09 PM, John Calcote wrote: Bruce, On 9/28/2009 7:03 PM, David Bruce wrote: Sorry David, then I went and got your first and last names mixed up. Perhaps I'd better just be quiet now. ;)

Re: "make dist" and "make distcheck" trouble

\ . options.c ^ | | A stray '.' got inserted in the file list, which lead to the entire Dang! I'm sorry. I noticed that period, but a period is so small that I almost thought it was dust on my monitor! Then I looked a second time and re

Re: "make dist" and "make distcheck" trouble

stray '.' got inserted in the file list, which lead to the entire src directory getting dragged into the tarball. I don't quite understand the operation of automake and make well enough to see how this lead to the VPATH build failure (and hence failure of make distcheck), but at an

Re: "make dist" and "make distcheck" trouble

Hello Ralf, > Which Autoconf and Automake versions do you use? dbr...@penguinmaster:~/tuxmath-1.7.3$ automake --version automake (GNU automake) 1.11 dbr...@penguinmaster:~/tuxmath-1.7.3$ autoconf --version autoconf (GNU Autoconf) 2.64 (my usual development machine is Debian

Re: "make dist" and "make distcheck" trouble

* David Bruce wrote on Mon, Sep 28, 2009 at 01:08:58AM CEST: > On 9/27/09, Ralf Wildenhues wrote: > > * David Bruce wrote on Sat, Sep 26, 2009 at 04:51:01AM CEST: > >> My project is not creating valid tarballs with "make dist", and "make > >>

Re: "make dist" and "make distcheck" trouble

Hello Ralf, On 9/27/09, Ralf Wildenhues wrote: > Hi David, > > * David Bruce wrote on Sat, Sep 26, 2009 at 04:51:01AM CEST: >> My project is not creating valid tarballs with "make dist", and "make >> distcheck" fails at the VPATH build stage. > >

Re: "make dist" and "make distcheck" trouble

Hi David, * David Bruce wrote on Sat, Sep 26, 2009 at 04:51:01AM CEST: > My project is not creating valid tarballs with "make dist", and "make > distcheck" fails at the VPATH build stage. Please post your Makefile.am files in toplevel and src. We might also need to

"make dist" and "make distcheck" trouble

My project is not creating valid tarballs with "make dist", and "make distcheck" fails at the VPATH build stage. 1. My project has all the *.c source files in a src directory under trunk. I normally always do vpath builds, and the svn src directory contains no object fi

--gnits, AC_INIT and VERSION

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There was discussion about getting version numbers from VCS recently; I've done a slightly different thing for a while now: AC_DEFUN([SUBUNIT_MAJOR_VERSION], [0]) AC_DEFUN([SUBUNIT_MINOR_VERSION], [0]) AC_DEFUN([SUBUNIT_MICRO_VERSION], [2]) AC_DEFUN([S

Re: distcheck and uninstall

On Sat, 2009-09-19 at 08:33 +0200, Ralf Wildenhues wrote: > No, I don't, but automake/NEWS indicates that it should've been around > 1.7, and 'git show Release-1-7:lib/am/distdir.am' looks good, too. Thanks again, Rob signature.asc Description: This is a digitally signed message part

Re: distcheck and uninstall

gnu.org/software/automake/manual/html_node/Checking-the-Distribution.html>. > > Sweet, thanks. Do you recall when that target was added? [So I can make > sure that that version of automake is my required minimum..] No, I don't, but automake/NEWS indicates that it should've been around 1.7, and 'git show Release-1-7:lib/am/distdir.am' looks good, too. Cheers, Ralf

Re: distcheck and uninstall

Hello Robert, * Robert Collins wrote on Sat, Sep 19, 2009 at 06:16:25AM CEST: > It would be nice if there was an option to tell automake not to (do > 'uninstall' as part of distcheck | require that uninstall leaves no > files behind) You can do the latter by overriding either distuninstallcheck r

Re: distcheck and uninstall

On Sat, 2009-09-19 at 08:24 +0200, Ralf Wildenhues wrote: > Hello Robert, > > * Robert Collins wrote on Sat, Sep 19, 2009 at 06:16:25AM CEST: > > It would be nice if there was an option to tell automake not to (do > > 'uninstall' as part of distcheck | require that uninstall leaves no > > files be

distcheck and uninstall

It would be nice if there was an option to tell automake not to (do 'uninstall' as part of distcheck | require that uninstall leaves no files behind) distcheck is very useful, it catches many distribution related bugs like missing EXTRA_DIST and so on. However, uninstall as a target is

Re: Fortran and flag ordering

if the user hasn't passed any. You can avoid that by passing them explicitly ./configure CFLAGS= CXXFLAGS= ... as user; and you can avoid the default setting as developer by saving their value before the respective macro, and restoring them afterwards. Remember, the user should always be able

Fortran and flag ordering

When I put fortran sources in a binary that also contains C sources, the compiler optimization flags get messed up. Observe: bin_PROGRAMS = xx xx_SOURCES = a.c a.f95 yields: gcc ... -g -O2 ... gfortran ... -g -O2 ... Cool. Now changing it like this: bin_PROGRAMS = xx xx_SOURCES = a.c a.f95 x

Re: CFLAGS and CXXFLAGS

ompiler nor CXXFLAGS to the C compiler. The user ought to be able to choose different compilers (even from different vendors) for each; also, there are compiler suites where the C and the C++ compiler have a different supported option set. CPPFLAGS are passed to both compilers, however, as they both

Re: CFLAGS and CXXFLAGS

On Wed, 9 Sep 2009, Dan Smithers wrote: Should the C++ compiler use the CFLAGS passed into automake? or do I need to manually include them in CXXFLAGS? CFLAGS and CXXFLAGS need to be different since the C and C++ compilers don't necessarily support the same options. CPPFLAGS is s

CFLAGS and CXXFLAGS

Should the C++ compiler use the CFLAGS passed into automake? or do I need to manually include them in CXXFLAGS? thanks dan

My approach for moving PACKAGE and VERSION

Hello again, Following the earlier thread a few months back ("RFE: allow for computed version number"), I was looking for a solution to this problem at the time, and implemented a scheme similar to that proposed. In case it's useful for anyone else, I'll detail what I'

automake and -Fe option for icl intel compiler c++

I am right now trying to compile a c++ code using autoconf and automake. I have been able to compile this code using autoconf and automake under a linux 64 platform, using the g++ compiler. On windows XP 32 platforms, using cygwin, I have been able to compile the same code, using the icl c

Re: vpath builds and nobase_include_HEADERS

build tree, there exist files sub/sub1/foo.h sub/sub2/bar.h and upon 'make install', they will be installed in $(foobardir)/sub1/foo.h $(foobardir)/sub2/bar.h Thus it is wrong to specify nobase_include_HEADERS = \ comp1/comp1.hh \ comp1/processed.hh in lib/comp1/M

Re: vpath builds and nobase_include_HEADERS

Hi Peter, * Peter Johansson wrote on Fri, Jun 05, 2009 at 07:50:56PM CEST: > Ralf Wildenhues wrote: >> could you please post this on-list unless it has huge size; that way, >> others can profit (or comment, critize, help, ...), too. >> > Sorry, I don't understan

Re: vpath builds and nobase_include_HEADERS

Hi Ralf, Ralf Wildenhues wrote: could you please post this on-list unless it has huge size; that way, others can profit (or comment, critize, help, ...), too. Sorry, I don't understand. I attached the tarball and CC:d the automake list. Are attachments filtered away when automake li

Re: Re: vpath builds and nobase_include_HEADERS

Hello Peter, > On Jun 5, 2009 8:42am, Peter Johansson wrote: > >> I've attached a modified version of your package for which `make >> distcheck' works. I'm not sure what structure you desire for the >> installed header files, but that should be easy to adjust. could you please post this on-l

Re: vpath builds and nobase_include_HEADERS

johnwohlb...@gmail.com wrote: Thanks very much for the help Peter. The goal is to have the headers installed and preserve the directory structure of the src. ie, after make install @prefix@/include/comp1/ comp1.hh processed.hh @prefix@/include/comp2/ comp2.hh I haven't yet looked at

Re: Re: vpath builds and nobase_include_HEADERS

re for the installed header files, but that should be easy to adjust. Hope this helps in a direction towards what you want to achieve. Cheers, Peter -- Peter Johansson Thanks very much for the help Peter. The goal is to have the headers installed and preserve the directory structure o

Re: vpath builds and nobase_include_HEADERS

Thanks again for the help Ralf. > > If that still doesn't help, it is useful to post a small example > > package. > Attached is an example package. What I left out of my original email was that I'm putting the Makefile.am's out of the src/ directory to enable building other architecture specific

Re: vpath builds and nobase_include_HEADERS

(header_file_list) > > The above is ok, the below is not. You should keep the above two lines and just drop the next 8 lines: > > lib1/header1.hh : lib1 > > for file in $(header_file_list) ; do \ > > nobase_file="`echo $$file | sed -e 's?lib1/??'`&quo

Re: vpath builds and nobase_include_HEADERS

Hello John, * johnwohlb...@gmail.com wrote on Thu, Jun 04, 2009 at 12:24:29AM CEST: > I'm having troubles with out of tree (vpath) builds, using > nobase_include_HEADERS, and *.in files processed by configure. I think you're making things more complicated than they need to

vpath builds and nobase_include_HEADERS

I'm having troubles with out of tree (vpath) builds, using nobase_include_HEADERS, and *.in files processed by configure. I have a collection of components in a component library. src/ src/lib1/ Makefile.am header1.hh types.hh.in source1.cc src/lib2/ Makefile.am header2.hh source2.cc I

Re: Automake 1.10.2 and color-tests

On Sat, May 9, 2009 at 4:59 AM, Ralf Wildenhues wrote: > Hello, > > * NightStrike wrote on Sat, May 09, 2009 at 10:51:15AM CEST: >> I'm trying to use the new color-tests option as documented here: >> >> http://www.gnu.org/software/hello/manual/automake/Tests.html#Tests > >

Re: Automake 1.10.2 and color-tests

Hello, * NightStrike wrote on Sat, May 09, 2009 at 10:51:15AM CEST: > I'm trying to use the new color-tests option as documented here: > > http://www.gnu.org/software/hello/manual/automake/Tests.html#Tests

Automake 1.10.2 and color-tests

hen I put color-tests in my AM_INIT_AUTOMAKE in configure.ac and run autoreconf, I get this: configure.ac:9: option `color-tests' not recognized autoreconf: automake failed with exit status: 1 When I put it instead in AUTOMAKE_OPTIONS in my Makefile.am, I get this: Makefile.am:13: opti

Re: Doxygen and Autotools

Thanks John, I'll take a look (actually I had already seen your online book, but not the part on doxygen). However, I think that some macro/base functionality should be provided in autotools, and I read in this very list that the autoconf macro does not work well... cheers Lo

Re: Doxygen and Autotools

Hi Lorenzo, Please see my on-line Autotools book at freesoftwaremagazine.com. It covers extensively the use of doxygen as an add-on to Autoconf and Automake. http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool Chapters 6 and 7 deal more specifically with

Doxygen and Autotools

Hi I've just started using doxygen for documenting a C++ library which I'm developing with autotools. I found this macro http://autoconf-archive.cryp.to/ax_prog_doxygen.html and this example http://www.bioinf.uni-freiburg.de/~mmann/HowTo/automake.html however, from what I under

Re: mingw compiler on cygwin, and path issues

Hello Jan, * Jan Engelhardt wrote on Fri, Apr 10, 2009 at 10:23:53PM CEST: > Given: > > AM_LDFLAGS = -L../subproject > foo_LDADD = -lsub For in-tree libraries always use relative paths to the .la file: foo_LDADD = ../subproject/libsub.la you can omit the AM_LDFLAGS. Does the issue remain wit

Re: mingw compiler on cygwin, and path issues

project\subproject >instead of c:\cygwin\home\user\project. [...] Secondly, the use of libtool suffocates the potential success of cygpath -m. Given: AM_LDFLAGS = -L../subproject foo_LDADD = -lsub automake will call libtool as usual, and libtool will expand it to a cygwin path only: /bin/sh ../li

mingw compiler on cygwin, and path issues

Hi, I am currently using automake in a Windows-related project; there is a (pure) mingw compiler in c:\mingw, and cygwin is installed in c:\cygwin. Now I noticed that Makefile.in, as generated by automake, has a CYGPATH_W variable which is `echo` on Unices, and `cygpath -w` on Cygwin. The

Re: Bison and flex target

, Apr 03, 2009 at 02:51:50PM CEST: > >>> I see there is AC_PROG_YACC and AC_PROG_LEX to get the apropriate > >>> programs for the configure.ac. But how do you go about adding them as > >>> build targets so: > >> Try something like > > > >>

Re: mostlyclean and texinfo outputs

[ let's drop bug-gnulib ] Hello Bruno, Karl, all, * Bruno Haible wrote on Fri, Apr 03, 2009 at 12:58:26PM CEST: > > > > For the {dvi,ps} formats this is (arguably) a bug in automake, > > > > I agree; automake should remove {html,dvi,ps,pdf} only upon 'clean', but > > not upon 'mostlyclean'. On

mostlyclean and texinfo outputs (was: Installing gnulib from git)

they see "There's too much clutter in this directory". > This is what doc/Makefile does. Yet, conceptually it is awkward to do file creation and file removal in one step. > By comparison, the automake generated gettext/gettext-tools/doc/Makefile > does this: > > $

Re: Troubles with proc*C and automake version 1.10

Hello, * acprdoer wrote on Thu, Apr 02, 2009 at 08:30:45AM CEST: > > Hi, thanks for the answer. > I've tried removing the verifierCoherence.c and put the verifierCoherence.pc > in the verifierCarte_SOURCES but the Makefile.in isnt generated : > > automake: readin

Re: Troubles with proc*C and automake version 1.10

Hi, thanks for the answer. I've tried removing the verifierCoherence.c and put the verifierCoherence.pc in the verifierCarte_SOURCES but the Makefile.in isnt generated : automake: reading COHERENCE/Makefile.am automake: Sources ending in .pc become .c automake: Sources ending in .c beco

Re: Troubles with proc*C and automake version 1.10

Hallo Annie, * acprdoer wrote on Wed, Apr 01, 2009 at 03:16:04PM CEST: > The project has migrated to solaris 10 and a new version of automake > (1.10.2), it was previously on Solaris 8 with an automake version 1.4. The > automake dos not produce any makefile.in on the new server

Troubles with proc*C and automake version 1.10

Hi, The project has migrated to solaris 10 and a new version of automake (1.10.2), it was previously on Solaris 8 with an automake version 1.4. The automake dos not produce any makefile.in on the new server : it says : automake: reading COHERENCE/Makefile.am automake: Sources ending in .pc

ylwrap and flex --header-file

Hi, when one uses --header-file in conjunction with ylwrap, the header file is produced in the temporary directory ylwrap runs in instead of ${srcdir}. I think this should be addresses somehow - I'm open to suggestions or ideas on how this could be tackled. One way would probably just to add

Re: SunOS4 compatibility (was: automake/533: DISTFILES containing a directory and files in that directory)

On Sun, 22 Mar 2009, Ralf Wildenhues wrote: Oh brother. According to autoconf.info, SunOS4 'cp' did not support the -f option. Anyone think we still need 'make dist' to work there? I don't think that support for 'make dist' on a bare system is necessary. This is not even close to a modern

SunOS4 compatibility (was: automake/533: DISTFILES containing a directory and files in that directory)

[ adding automake@; this is ] * Ralf Wildenhues wrote on Sun, Mar 22, 2009 at 10:17:06AM CET: > --- a/lib/am/distdir.am > +++ b/lib/am/distdir.am > @@ -202,10 +202,16 @@ endif %?TOPDIR_P% > ## directory exists only in $(srcdir)

Re: AC_PROG_OBJC and automake 1.9

> This error does not appear with automake 1.10 (afaik). Yes; the corresponding fix went in in 1.9a and is in 1.10: <http://git.savannah.gnu.org/cgit/automake.git/commit/?id=b9df3285f2c32960ebeb979bbc6d76ea3e438ba4> I suppose you can work around this bug by changing your code to

AC_PROG_OBJC and automake 1.9

with automake 1.10 (afaik). I don't know why the author use m4_ifdef to check the compiler. So I would like to know what is the best way to check for objective c compiler and what are the possible problems with respect to automake versions. thank you Vincent Torri

[PATCH v2 2/3] AX_DIST_RPM (and dependent macros) Modified to use AX_ADD_AM_MACRO_STATIC.

The macros AX_UPLOAD, AX_INSTALL_FILES, and AX_EXTRA_DIST which are often used in conjunction with AX_DIST_RPM were also updated to use AX_ADD_AM_MACRO_STATIC. Thanks go to Ralf Wildenhues for the idea of adding local cleanup and distribution targets as prerequisites the *-local/*-hook targets

[PATCH v2 1/3] AX_ADD_AM_MACRO_STATIC: Added a new macro and helpers.

would imply and b) only works for implementations of Make which allow includes, BSD Make and GNU Make are the only ones that come to mind. Hopefully this new macro will eventually replace the existing one altogether because it allows Automake to do the actual work thereby offering more por

Re: Built sources and make distcheck

e set up correctly [...] > > I'm not really sure how else you could have generated.c on the source > > tree and not break dist-check, but then I'm probably missing something > > obvious. > > With distcheck, the rule for generated.c should never be invoke

Re: Built sources and make distcheck

ou could have generated.c on the source > tree and not break dist-check, but then I'm probably missing something > obvious. With distcheck, the rule for generated.c should never be invoked in the first place, as the distributed file should be up to date wrt. its prerequisites. > Als

Re: Built sources and make distcheck

lookup_SOURCES = lookup.c $(srcdir)/generated.c > > I've got it living in $(srcdir) now, thanks. I can't see why your > version of a lazy update would speed it up though. It still runs > ./generate, and now it's running diff too, right? The version Ralf provided always r

Re: Built sources and make distcheck

eed to be generate$(EXEEXT). Oh, right. >> ./generate$(EXEEXT) >$@ >> >> bin_PROGRAMS = lookup >> lookup_SOURCES = lookup.c generated.c > > You need to use BUILT_SOURCES, and fake dependencies so that no > distributed file depends on an undistributed one. Untested: >

Re: Built sources and make distcheck

t; bin_PROGRAMS = lookup > lookup_SOURCES = lookup.c generated.c You need to use BUILT_SOURCES, and fake dependencies so that no distributed file depends on an undistributed one. Untested: EXTRA_PROGRAMS = generate BUILT_SOURCES = generate$(EXEEXT) generated.c: generate.c Makefile.in ./generat

Built sources and make distcheck

I have a project which auto-generates some look-up tables when checked out from its SCM, and are distributed in the tarballs. These tables used to be made by shell scripts called from autogen.sh, but I recently ported them to C for a massive speed improvement. I've implemented the Makefi

Re: make dist and data package

the data directory ? I see two possibilities: you can write a fully separate dist-data rule, that also has its own recursive makefile machinery (in case you are using SUBDIRS), and implement all that manually, or you can hook into the dist-hook. It is invoked after the population of $(distdir) in

Re: automake and dist data

Hello, please don't top-post on this list; thanks. * dage...@free.fr wrote on Tue, Feb 10, 2009 at 07:06:01PM CET: > > I'm developping a middle-scale library that uses autoconf and > automake. This library comes along with some demo and test programs. > Those demo and tes

Re: automake and dist data

@free.fr wrote: > Hello, > > I hope someone here will be able to help me. > > I'm developping a middle-scale library that uses autoconf and automake. This > library comes > along with some demo and test programs. Those demo and test programs now > require some > in

automake and dist data

Hello, I hope someone here will be able to help me. I'm developping a middle-scale library that uses autoconf and automake. This library comes along with some demo and test programs. Those demo and test programs now require some input files in order to run. Those input files also have

make dist and data package

er your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.

automake-gnats: #533 and #535

Hi Ralf, recently I have reported two automake problems #533 and #535 (#534 duplicates #533, my mistake) with patch and test case. They have been assigned to Alexandre Duret-Lutz , but according to the git log his last activity was in June 2006. Maybe you can have a look. 533: applies equally

Re: C++, lex and automake

Andre Heine wrote: Hi Am Dienstag, 13. Januar 2009 18:27 schrieb Юрий Пухальский: I'm sure that it will work, but to me it looks as hacky as the %option approach. Shouldn't automake hide these nasty details from me? IMHO, automake should recognize the suffix, i.e. "*.lpp"

Re: C++, lex and automake

Andre, i think it can be done, as from what i've picked ylwrap operates in temporary directory anyway, so that should be no problem picking whatever lex has dropped, be it .c or .cc. As for recognizing the suffix - it might be troublesome for a file with .l extension having option c++ inside. The r

Re: C++, lex and automake

Hi Am Dienstag, 13. Januar 2009 18:27 schrieb Юрий Пухальский: > I'm sure that it will work, but to me it looks as hacky as the %option > approach. Shouldn't automake hide these nasty details from me? IMHO, automake should recognize the suffix, i.e. "*.lpp" for f

Re: C++, lex and automake

Good evening! Thank You for the reply, Andre! I'm sure that it will work, but to me it looks as hacky as the %option approach. Shouldn't automake hide these nasty details from me? Another problem i've stumbled upon: The same thing with files and renaming occurs when compiling b

Re: C++, lex and automake

Am Dienstag, 13. Januar 2009 16:25 schrieb Andre Heine: [...] > AM_LFLAGS = --c++ -o lex.yy.c -L AM_YFLAGS should be the correct parameter, sorry ... Andre -- While most peoples' opinions change, the conviction of their correctness never does.

Re: C++, lex and automake

Am Dienstag, 13. Januar 2009 12:08 schrieb Юрий Пухальский: > Good day! > > I've a lex file with %option c++. > Being processed by lex it produces by default a file named lex.yy.cc, > while automake expects it to be lex.yy.c when constructing a line with > ylwrap: > /bin/sh ./ylwrap engine_tcp_lex.

C++, lex and automake

Good day! I've a lex file with %option c++. Being processed by lex it produces by default a file named lex.yy.cc, while automake expects it to be lex.yy.c when constructing a line with ylwrap: /bin/sh ./ylwrap engine_tcp_lex.ll lex.yy.c engine_tcp_lex.cc -- flex -d Setting LEX_OUTPUT_ROOT doesn't

Re: automake EXTRA_DIST and filename spaces...

;make' prerequisites; file names with spaces cannot be used as 'make' prerequisites (even with GNU make) because of the Makefile syntax. As a suboptimal workaround, you could put the files that contain spaces in their names in a subdirectory (which does not have spaces in its name),

Re: automake EXTRA_DIST and filename spaces...

le names with spaces cannot be used as 'make' prerequisites (even with GNU make) because of the Makefile syntax. As a suboptimal workaround, you could put the files that contain spaces in their names in a subdirectory (which does not have spaces in its name), and then supply that subdirec

automake EXTRA_DIST and filename spaces...

ragon\ Quest\ I\ &\ II\ (J).cht I'm using automake 1.10 if it matters. I would prefer to keep the filename intact, ampersands, spaces, and parentheses included. make[1]: *** No rule to make target `"res/Dragon Quest I & II (J).cht"', needed by `distdir'. Sto

Re: Multilib sources and variables

On Sunday 2008-11-30 18:07, NightStrike wrote: >>> >>>>Is the following kosher? >>> >>>It will produce two 32-bit libraries on all architectures where >>>gcc defaults to a 32-bit output. >> >> (In other words, you are missing -m64. And

Re: Multilib sources and variables

* NightStrike wrote on Sun, Nov 30, 2008 at 06:08:39PM CET: > On Sun, Nov 30, 2008 at 2:32 AM, Ralf Wildenhues wrote: > > > > Typically, -m32 either goes right on to the compiler, or it goes in both > > CPPFLAGS and LDFLAGS. Since you don't link here, that looks ok. >

Re: Multilib sources and variables

ll32src=libsrc/shell32.c >> >> lib32_LIBRARIES += lib32/libshell32.a >> lib32_libshell32_a_SOURCES = $shell32src >> lib32_libshell32_a_CPPFLAGS = -m32 >> >> lib64_LIBRARIES += lib64/libshell32.a >> lib64_libshell32_a_SOURCES = $shell32src > >> Basicall

Re: Multilib sources and variables

n all architectures where >>gcc defaults to a 32-bit output. > > (In other words, you are missing -m64. And perhaps some logic > so that lib64 is not built in pure 32-bit environments.) That's ok. I have that covered elsewhere in the makefile. Also, this is for the mingw-w64.s

Re: Multilib sources and variables

On Sunday 2008-11-30 02:24, Jan Engelhardt wrote: >On Sunday 2008-11-30 01:52, NightStrike wrote: > >>Is the following kosher? > >It will produce two 32-bit libraries on all architectures where >gcc defaults to a 32-bit output. (In other words, you are missing -m64. And

Re: Multilib sources and variables

S = $shell32src > lib32_libshell32_a_CPPFLAGS = -m32 > > lib64_LIBRARIES += lib64/libshell32.a > lib64_libshell32_a_SOURCES = $shell32src > Basically, all the sources are the same, so I don't want to list them > twice (and subsequently maintain two lists and forget to keep updating

Re: Multilib sources and variables

On Sunday 2008-11-30 01:52, NightStrike wrote: >Is the following kosher? It will produce two 32-bit libraries on all architectures where gcc defaults to a 32-bit output. >shell32src=libsrc/shell32.c > >lib32_LIBRARIES += lib32/libshell32.a >lib32_libshell32_a_SOURCES = $shell32src >lib32_libshe

Multilib sources and variables

don't want to list them twice (and subsequently maintain two lists and forget to keep updating the two lists.) The only difference is adding the -m32 flag (which I'm hoping is correctly placed in CPPFLAGS, and not CFLAGS... I never remember which flags go where). So is it ok to do th

Re: pre- and post-compilation hooks

> This does eliminate duplicates, but references .processed.cpp in TAGS. > Ideas? Not good ones. You could overwrite $(SOURCES), but that may have other consequences, too. > > > > > Hmm, a nice trick! However, the preprocessor reads .cpp files, > > > > > possibly

Re: pre- and post-compilation hooks

Hello Ralf, On Tue, Nov 18, 2008 at 07:54:34PM +0100, Ralf Wildenhues wrote: > > However, I would really like to avoid duplicating every source file in > > maude_SOURCES and EXTRA_maude_SOURCES (the necessity to write a custom > > make clean and duplicated TAGS entries being

Re: pre- and post-compilation hooks

p `dirname [EMAIL PROTECTED] > cp $< $@ > > SUFFIXES = .cpp .processes.cpp > > However, I would really like to avoid duplicating every source file in > maude_SOURCES and EXTRA_maude_SOURCES (the necessity to write a custom > make clean and duplicated TAGS entries being

Re: pre- and post-compilation hooks

cdir)/myscript.py $< mkdir -p `dirname [EMAIL PROTECTED] cp $< $@ SUFFIXES = .cpp .processes.cpp However, I would really like to avoid duplicating every source file in maude_SOURCES and EXTRA_maude_SOURCES (the necessity to write a custom make clean and duplicated TAGS entries b

Re: pre- and post-compilation hooks

do the preprocessing. Even if they have suffixes like .c, you > > might be able to hack it by writing a rule like > > .c.processed.c: > > command > > SUFFIXES = .c .processed.c > > Hmm, a nice trick! However, the preprocessor reads .cpp files, possibly >

Re: pre- and post-compilation hooks

Hello Ralf, It turned out I'm not subscribed to the list and have missed some interesting stuff like less verbose. On Wed, Nov 12, 2008 at 09:34:22PM +0100, Ralf Wildenhues wrote: > > I'd like to migrate a SNiFF+ project to automake. So far, it looks quite > > promising.

Re: pre- and post-compilation hooks

alling the compiler; if pre-processing fails, the compiler >is not called, and make is stopped. What is SNiFF+, what does it do? What are the input files? If they have different suffixes than the compiler, you can just use a (suffix) rule to do the preprocessing. Even if they have suff

pre- and post-compilation hooks

Hello, I'd like to migrate a SNiFF+ project to automake. So far, it looks quite promising. Two issues: 1. The compilation rule performs some custom pre-processing before actually calling the compiler; if pre-processing fails, the compiler is not called, and make is stopped. 2. The Ta

Re: Chosing between system and builtin library

mentation looks complicated. Is there an easier way to > > do the job? I'm pretty sure there are some caveats to be aware of when > > specifying the library. > > I think so. FWIW libltdl is similar (but probably even more > complicated). > > Anyway, for a start I

Re: Chosing between system and builtin library

hen > specifying the library. I think so. FWIW libltdl is similar (but probably even more complicated). Anyway, for a start I'd try to use an AC_CONFIG_SUBDIRS in the toplevel package (ignores non-existent subdirs), a subdir conigure for the library, and set LIBFOO, LTLIBFOO, INCFOO (or what

Chosing between system and builtin library

(for distros). gettext's implementation looks complicated. Is there an easier way to do the job? I'm pretty sure there are some caveats to be aware of when specifying the library. In my case I'd like to repackage "ballz" (http://code.google.com/p/db-tins07/) which bundles 2 libraries (&

automake training tutorial: distcheck, separate build directory and generated files

IBTRAINING_BUILDDIR)/libtraining.la Is there a better way to do that, a libtool trick that I missed for example ? -- 2/ I want to create a minimal tar, so I can restart from scratch to test all autotools stuff... With autogen.sh. I'm using Subversion. And my top source directory is named &#x

Re: libtool (1.5.26) with mingw/msys and eclipse problem

On Fri, 2008-08-29 at 08:18 +0200, Ralf Wildenhues wrote: > Can you influence Eclipse's choice of shell to use? It is possible to change the way Eclipse runs the make command, but all my attempts to do so failed so far. > Please post the exact error (copy and paste), as well as the

Re: libtool (1.5.26) with mingw/msys and eclipse problem

up with is > that Eclipse calls "make" using *cmd.exe* instead of sh.exe (the latter > being used in MSYS), which of course returns Windows paths and not > MSYS/unixlike paths.. Can you influence Eclipse's choice of shell to use? > But the actual error is caused by the fol

<    5   6   7   8   9   10   11   12   13   14   >