Re: macro `AM_PROG_AS' not found in library

STyx wrote: > [EMAIL PROTECTED] /cygdrive/d/ST/dev/mysql/mysql-4.1 > $ aclocal > aclocal: configure.in: 539: macro `AM_PROG_AS' not found in library > > [EMAIL PROTECTED] /cygdrive/d/ST/dev/mysql/mysql-4.1 > $ aclocal --version > aclocal (GNU automake) 1.4-p6 Cygwin uses wrapper scripts for aut

Re: Tools under Windows

BRM wrote: > I wouldn´t mind using Cygwin as the build environment. > What I mind is having to have any dependancy from the > Cygwin build environment come into my project. As much > as I may like to, I can´t open source the project (not > my call to do so), and my customers won´t install > anythi

Re: top level make file with deep dir struct demo

Matt Hull wrote: > i was just thinking that. so i can do the top level makefile and use > autoconf/automake on the current system and configure and make should work > on the outdated ? That is why you include the configure script (and any other generated files) in your tarball. The person that

setting $VERSION at runtime

We have an application where the version number (for the purposes of creating a dist tarball) is determined by grepping for $Revision $ in the toplevel ChangeLog. Because this is not a static value, it means we can't just set VERSION when running automake, since a commit could cause it to bump wi

Re: Partial linking with _RELOCATABLES - Proposed enhancement

Ralf Wildenhues wrote: > - There are some systems where partial linking is currently broken, > e.g. GNU binutils ld on w32: > http://sourceforge.net/mailarchive/message.php?msg_id=14729192 > I have not investigated whether a newer version has this fixed yet. I tried building geos-2.2.1 und

Re: Partial linking with _RELOCATABLES - Proposed enhancement

Ralf Wildenhues wrote: > Which libtool(ize) version was used? What's the output of > ../../libtool --config | grep "^max_cmd_len" The libtool version is the 1.5.20-2 Cygwin package. max_cmd_len=8192. > Anyway I guess the difference is that the report speaks about the CVS > HEAD version of li

Re: make distcheck not finding custom code generation script

Andreas Ntaflos wrote: > So to translate foo.ice to foo.cc and > foo.hh I need to run (in my $(topdir)/src subdirectory) > > ../tools/wrapper.sh /path/to/foo2cpp foo.ice > > In src/Makefile.am there is a target that does just that: > > foo.cc foo.hh: foo.ice > $(ICE_FOO2CPP) foo.ice > [

Re: Libraries in non-standard locations

Norbert Sendetzky wrote: > As you can see the call to libtool include the "-L /usr/lib/mysql", but the > gcc call doesn't. My Makefile.am for this lib is It is incorrect to put a space between -L and the path. Fix that and it should work fine. Brian

Re: Problem with building .info files?

Daniel Franke wrote: > Interestingly, the according dvi, pdf and html targets are built in > $(builddir): > > ... > > Which results in libgomp.{dvi,pdf,html} in $(builddir) and libgomp.info in > $(srcdir). At the very least, this behaviour is inconsistent. It's consistent with the fact that the

Re: Installation dirs in code

Brendon Costa wrote: > I have a program that requires a configuration file that will usually go > into the ${prefix}/etc as given by $sysconfdir. So this program needs to > know where it is going to find this installed configuration file. I was > initially going to export the evaluated value of $s

Re: Installation dirs in code

Brendon Costa wrote: > However all these methods of obtaining the directory information seems > to fall down for libraries. Huh? Did you read the same email by Bruce Haible that I did? Because it doesn't fall down at all. On Win32 GetModuleFilename works just fine to tell you the DLL name, and

Re: problem with a test that is expected to fail, on cygwin only...

Ed Hartnett wrote: > TESTFILES = nctst tst_failure > [...] > TESTS = $(TESTFILES) run_nc_tests.sh > XFAIL_TESTS = tst_failure > [...] > XFAIL: tst_failure > [...] > FAIL: tst_failure.exe Notice the difference? You probably should specify "TESTFILES = nctst$(EXEEXT) tst_failure$(EXEEXT)" and "XFA

Re: warnings with automake 1.10 on cygwin / pstoedit.m4, libsmi.m4, etc.

David Byron wrote: > on line 7. I went ahead and changed it to: > > AC_DEFUN([AM_PATH_PSTOEDIT], > > and the warning disappeared, revealing a different one. As I fix each one > the same way, a new one appears. Here are the rest. > > /usr/share/aclocal/libsmi.m4:8: warning: underquoted defini

Re: Automake violations of the gnu coding conventions

"K. Richard Pixley" wrote: > My question today is... is there any hope of bringing automake generated > Makefiles back into line with the GNU coding standards so that these > applications will work once again? This is already supported, just add AM_MAINTAINER_MODE and the rules to rebuild generat

Re: Automake violations of the gnu coding conventions

"K. Richard Pixley" wrote: > even be interested in regenerationg Makefile.in's automagically. As is, > typical builders, (ie, not maintainers), are required to install > automake in order to build packages requiring automake. I think you're generalizing this to a degree that's not the case. Mos

Re: %-style pattern rules

Lorenzo Bettini wrote: > after upgrading to automake 1.10 I get these warnings > > Makefile.am:47: `%'-style pattern rules are a GNU make extension > > about rules of the shape, e.g., > > %.txt: %.tt > > how else could I implement those make rules? The warning is telling you that using that c

Re: .o naming seems strange

Jan Engelhardt wrote: > CC ccgfs_mount-mount.o ( mount.o ) > CC ccgfs_mount-packet.o( packet.o ) Your Makefile.am defines ccgfs_mount_CFLAGS. > CC storage.o ( ccgfs_storage-storage.o ) > CC packet.o( ccgfs_storage-packet.o )

Re: Makefile.am assistance

Ralf Wildenhues wrote: > Well, I could tell you that Libtool can create DLLs plus import > libraries (it names them libfoo.dll.a), but I don't think you want > to hear that at this point. ;-) Libtool isn't appropriate here because he's not actually building any libraries, only synthesizing impor

Re: Cannot see CFLAGS

Hongliang Wang wrote: > zizzy_LDADD = ../gen/libzizzy.a ../ora/libzizora.a > zizzy_CFLAGS = -Wall -Werror `pkg-config --cflags glib-2.0` > zizzy_LDFLAGS = -ggdb `pkg-config --libs glib-2.0` -lfoo (which is likely the result of `pkg-config --libs ...`) does not go in LDFLAGS. You should put that

Re: AM_LIBS / AM_LDADD

NightStrike wrote: > Regarding libtool, maybe I just don't understand how libtool works. I > can't figure out how to use libtool to generate lib*.a. It seems > intent on restricting outputs to only lib*.la. I eventually gave up > and started manually invoking dlltool myself to build the lib*.a

Re: What to check into repository?

Warren Young wrote: > You can create empty versions of these files to appease the tool. (Per > the thread topic, they would go in the repository.) Or, maybe you have > a use for some of these files, so they could have actual content. He has them in a doc/ subdir, so it would be rather ugly to p

Re: Automake (alpha) release request

Sebastian Pipping wrote: > Bob Friesenhahn wrote: > > The license update can simply be temporarily reverted back to v2 (with > > FSF approval). > > I'd like to see that as well but I doubt it will happen. It's not politically feasible since official GNU projects are supposed to reflect the GNU p

Re: Problems with headers and subdirectories

Stefan Bienert wrote: > and after this, noinst_HEADERS is not used anymore. Should'nt > noinst_HEADERS be set before line 49? Variable assignments with '=' (as opposed to ':=') in Makefiles use deferred expansion, meaning that values are recursively substituted at the point at which the variable

Re: stamp-h.in

Ralf Wildenhues wrote: > This is what I found using "git -Sstamp-h.in": However, automake still makes use of "stamp-h" witness files, it's just that they are created and deleted as needed automatically, without the need for some ".in" template to remain anywhere, correct? Brian

precompiled headers (was: Slow compilation with many files)

Per Rosengren wrote: > My only problem now is how to get my buildsystem to use it. I am > currently using autoconf and automake. If I run "gcc -c myheader.hh", I > get a myheader.hh.gch file. I have tried to add the headers to > SOURCES in Makefile.am, but the resulting Makefile doesn't > compile

Re: extending automake

Bob Rossi wrote: > EXTRA_DIST = foo.xml > > BUILT_SOURCES = foo.h foo.cc > > foo.h foo.cc: $(srcdir)/foo.xml $(top_srcdir)/gen.py > python $(abs_top_srcdir)/gen.py $(srcdir)/foo.xml This is not good. When you write: target1 target2: prereq recipe It is really shorthand for: target

Re: extending automake

Bob Rossi wrote: > verbose). Why are you not sure this is a good idea? I sort of feel like there are "workspaces", the configure area and the make area. This parallels the idea that there are configure-substituted variables and make-substituted variables, the latter can be changed/overridden whe

Re: extending automake

Ralf Wildenhues wrote: > Well, this scheme can easily be generalized to one stamp file per set of > output files, no? And then it parallelizes well, too. Yes, I suppose if you named the stamp with a filename derivable from that of the .xml filename you could generalize this without having to wri

Re: extending automake

Ralf Wildenhues wrote: > This thread has some ideas: > > > If you (or anybody) finds the above useful, and think the setup is > general enough for several use cases, we can think about how to > integrate it into Automa

Re: extending automake

Ralf Wildenhues wrote: > Do you mean that, given that keyword, all rules of the form > target1 target2 : prereq ... > command ... > > should be rewritten to be a multiple-target rule? Yeah. > Ugh. That would > violate the "input appears in output" quite heavily. Sure, but that's alr

Re: Cross compiling with pkg.m4

John Darrington wrote: > pkg.m4 doesn't behave in a very rational way, when configured with > --host=xyzzy > > All the PKG_CHECK_MODULES macros continue to find the local modules, > not the ones for target xyzzy.Consequently, the build fails when > the compiler/linker can't find the header/li

Re: patch and dist rules

Jack Bates wrote: > I created a "patch" rule in our application Makefile.am for applying > these patches: > > patch: patch-stamp > patch-stamp: patches/* > cat patches/* | patch -p0 > > touch $@ It seems to me like this would break VPATH builds since it assumes you're building i

Re: preprocessor output target

Jason Roscoe wrote: > I apologize if this is not the correct list but maybe someone here can > answer ... I have a project that uses autoconf/automake and libtool. I > was wondering if there is already a macro that will create Makefile > targets for getting the preprocessor output. For example,

Re: Simple "how-to" question, libtool

Mar Loh wrote: > Q1: Every time I run ./configure from the topdir, the system checks > (checking for BSD-compatible) are re-run every time it gets to a new > subdirectory, making the configure take a long time. How do I remove these > checks when going to a new subdirectory (these are clearly

Re: Dependencies: non-standard path to system headers

Ineiev wrote: > WinAVR gcc produces dependencies that shall confuse `make', > like these: The essential point is that using native Win32 tools with Cygwin causes problems. This is because Cygwin is designed to closely emulate a POSIX environment, and the tools aren't equipped to deal with Win32

Re: Dependencies: non-standard path to system headers

[EMAIL PROTECTED] wrote: > Some strictly positive amount of interoperability exists. > When I gcc c:/cygwin/home/15-6-1/tmp/m/sample.c, it > produced a.exe (gcc 'c:\cygwin\home\15-6-1\tmp\m\sample.c', too). > > sample.c contained > #include > int > main(void) > {FILE*f=fopen("c:\\sample.txt","w")

Re: correct windres use

Vincent Torri wrote: > .rc.o: > $(WINDRES) -o $@ $< > > pkg_LTLIBRARIES = module.la > > module_la_SOURCES = \ > evas_wince_gapi.rc \ > other_source_files > > But windres is not called and evas_wince_gapi.rc is ignored. There are roughly two problems here, mostly independent: A. autom

Re: Warn: non-POSIX variable name

Steven Woody wrote: > How do I remove these warnings when do automake: > > src/rmeterd/Makefile.am:9: shell ../../svndate-sh: non-POSIX variable name > src/rmeterd/Makefile.am:9: (probably a GNU make extension) > > in the Makefile.am, I did something like this: > > rmeterd_CXXFLAGS

Re: Warn: non-POSIX variable name

Steven Woody wrote: > Thank you. Adding -Wno-portablility to AM_INIT_AUTOMAKE works. But I > don't understand your other words: "For the former, > run the script at configure-time rather than at make-time and AC_SUBST > the resulting value." I mean adding something like the following to configu

Re: Questions on exporting functions from a shared library

Jef Driesen wrote: > What are the (dis)advantages of each method? I see differences in usage > (see below), but are there technical differences as well? It sounds like you already are aware of all the tradeoffs. I don't think there's a technical difference in the end, i.e. the results are the sa

Re: Questions on exporting functions from a shared library

Jef Driesen wrote: > The MSDN documentation [1] about this issue, gives me the impression > that applications have to relink when new symbols are added to the > library (when not using a DEF). And that's something I would like to > avoid. Actually this statement surprises me, so I'm probably just

Re: Questions on exporting functions from a shared library

Jef Driesen wrote: > And how about gcc < 4.0 that do not support the visibility attributes? > Is there a way to hide non-public symbols? Is the version script still > available in this case? Is it possible to use both the attributes and > the -export-symbols together? There are two aspects to the

Re: Kdevelop + automake problems

Bryan Bennetts wrote: > So question #1 is should aclocal.m4 be in my distribution? Strictly speaking, a user should not even need m4 installed at all (nor autoconf, nor automake, etc) to run the configure script and build the software. However common courtesy dictates that you should distribute

Re: multiple targets, different build options

John Richetta wrote: > clumsier for the maintainer. But I am sure automake must provide > some way of achieving functionality equivalent to this essential make > capability - no? The automake way of doing this is with separate build directories, not by hard coding any special rules into the buil

Re: building a qt library

Lorenzo Bettini wrote: > this approach does not seem to work: probably the qt-mt.pc shipped in > the installation in cygwin is not correct since it uses -lresolv > (libresolv) which is not installed... Install the minires-devel package then, which contains that library. Brian

Re: building a qt library

Lorenzo Bettini wrote: > yes of course I did, I was only saying that these requirements/deps > should be documented somehow ;-) They already are. Take a look at /usr/share/doc/Cygwin/qt3-*.README and you'll see minires-devel listed among the packages listed as build requirements. > this is prob

Re: Recursive source inclusion

Ralf Wildenhues wrote: > How about adding it to a convenience archive, and then adding that to > your build. In this case, add > > noinst_LIBRARIES = libcore.a > libcore_a_SOURCES = core.c > > to src/Makefile.am, and add > gtkapp_LDADD = ../libcore.a > > to gtk/Makefile.am. Inside src/M