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
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
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
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
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
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
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
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 = \
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. automake itself
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
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, if
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/library
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 when
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
Ralf Wildenhues wrote:
This thread has some ideas:
http://thread.gmane.org/gmane.comp.sysutils.automake.general/8916/focus=8924
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 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 already
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
targetSOURCES in Makefile.am, but the resulting Makefile doesn't
compile
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:
target1:
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
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
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
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 put
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
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 in
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 import
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 )
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 construct
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.
Most
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 definition of
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 XFAIL_TESTS =
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
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
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 GNU
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
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 under
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
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
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
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
anything
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
40 matches
Mail list logo
