Hi,
Akim Demaille wrote:
It is possible to do the internationalization in such a way, that
automake would still run without libintl-perl being installed.
License problems should not be an issue, libintl-perl is distributed
under the LGPL. As for the required Perl version, Perl
Hi there,
With current CVS automake, 'make distcheck' fails on automake,
because readonly file version.texi in readonly directory
cannot be written to.
I suppose the change from 2003-11-08 caused this, but as I don't
understand all the implications, I won't suggest a fix.
Regards,
Ralf
[ after
Akim Demaille wrote:
But I hear your point, I just beg to differ on the relative
importance.
I tend to agree. It's more important to make automake support po/ directories
in an easier way _in_general_ (and get rid of gettextize). A proposal in this
direction is at
Denis Barbier wrote on 2003-11-12:
The 8-year old way of distributing a PO file directory has several drawbacks:
- requires separate files (POTFILES.in, Makevars) for customization,
I can hardly see why this is a drawback. You added support for a
separate po/LINGUAS file in 0.11, and it
Scott == J Scott Amort [EMAIL PROTECTED] writes:
Scott - include
Scott - src
Scott- subdir1
Scott- subdir2
Scott - extra
Scott - build
Scott- src
Scott The configure.ac, Makefile.am, etc. files are located in the
Scott src subdirectory of the build directory at the bottom (nothing
Jirka == Jirka Hanika [EMAIL PROTECTED] writes:
Jirka My view is that these (and other) problems disappear if you use a
Jirka per-directory Makefile.am; but I also see the benefits (esp. compilation
Jirka speed) of a non-recursive Makefile. So the solution could be to support
Jirka generating a
i see from the previous post that you use a manual VPATH methodology.
there are two approaches you can try:
1/ undo the unorthodoxy (move auto* files to top-level dir)
2/ prefix relative paths (such as ../../) w/ $(srcdir)
probably 1/ is the best for minimizing gray hairs long term, although it
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
Marty == Marty Leisner [EMAIL PROTECTED] writes:
adl [...]
Marty common/Makefile.am:1: directory should not contain `/'
Marty Just wondering for some thoughts on this matter...is
Marty there any reason to insist on single level source
On 9 Dec 2003, Tom Tromey wrote:
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes:
Bob In other words, dealing with junk like
Bob apps_build_postgres_src_build_postgres_SOURCES
Bob is very tiring and failure prone. Is there a reason why it can't
Bob simply be
Bob
Bob == Bob Friesenhahn [EMAIL PROTECTED] writes:
Bob In other words, dealing with junk like
Bob apps_build_postgres_src_build_postgres_SOURCES
Bob is very tiring and failure prone. Is there a reason why it can't
Bob simply be
Bob apps/build-postgres/src/build-postgres_SOURCES ?
Yeah, that does
I have a C program that uses a library which internally uses C++, but
exposes a C API. I have a user who experiences linking problems about
missing standard C++ stuff, fixed by using g++ to link. I am looking
for help in understanding this and what the correct solution is.
This has been
Thanks for the response!
On Tue, 2003-12-09 at 08:05, Thien-Thi Nguyen wrote:
i see from the previous post that you use a manual VPATH methodology.
there are two approaches you can try:
1/ undo the unorthodoxy (move auto* files to top-level dir)
2/ prefix relative paths (such as ../../) w/
On Tue, 2003-12-09 at 09:27, Tom Tromey wrote:
Yeah, you can do this. It's a bit more idiomatic to list header
files in a _SOURCES somewhere. They are ignored for purposes of
compilation, but are distributed.
Thanks for the advice - I'll move the header files into the _SOURCES
list.
Best
On Wed, 2003-12-10 at 05:06, Tom Tromey wrote:
It isn't impossible. I once wrote up some ideas along these lines:
http://sources.redhat.com/ml/automake/2001-07/msg00248.html
Obviously I never got around to implementing this :-)
Have you looked at either of my proof-of-concepts?
Rob
Ralf == Ralf Wildenhues [EMAIL PROTECTED] writes:
Ralf Hi there,
Ralf With current CVS automake, 'make distcheck' fails on automake,
On which OS? with which version of Make, sh, etc.?
Ralf because readonly file version.texi in readonly directory
Ralf cannot be written to.
Ralf I suppose
AFAIK There's a third possibility : you could setup a dist-hook target
in Makefile.am which allows you to specify completely your dist rule (I
had the same problem than yours and used this method). Unfortunately, it
also means that you might have to update this rule each time you change
metadata
... moving everything into the top-level dir (#1) did solve the
problem. Unfortunately, I don't currently have any control over the
directory structure (the motivation behind the attempt is to keep
platform specific items, i.e. *nix makefiles, VC++ 6 project files,
etc. in
On Tue, 9 Dec 2003, David Wolfe wrote:
AFAIK There's a third possibility : you could setup a dist-hook target
in Makefile.am which allows you to specify completely your dist rule
I suspect I'm too lazy for that. ;-) Seems like it would be more fun to
take a stab at hacking automake to
Alexandre == Alexandre Oliva [EMAIL PROTECTED] writes:
Alexandre the *_OBJECT definitions assume the absence of shell-active
Alexandre characters in filenames, which is probably a safe
Alexandre assumption for Makefiles.
It isn't unreasonable for a Java .class file's name to contain $.
libgcj
On Tue, 9 Dec 2003, Billy Biggs wrote:
I have a C program that uses a library which internally uses C++, but
exposes a C API. I have a user who experiences linking problems about
missing standard C++ stuff, fixed by using g++ to link. I am looking
for help in understanding this and what
Hi Bob, thanks for your reply.
Bob Friesenhahn ([EMAIL PROTECTED]):
On Tue, 9 Dec 2003, Billy Biggs wrote:
I have a C program that uses a library which internally uses C++,
[...]
1. Why does my program need to be linked with a C++ compiler in
some cases and not in others?
I am working to get the package I support to support the 'distcheck'
target. The distcheck target fails with:
ERROR: files left in build directory after distclean:
./GraphicsMagick-1.1-20031209.tar.gz
Unlike the many other problems that I have already had to solve, this
one looks like
(Answering only for Automake, because I've also been confused by
Akim's last statements about announcements that shouldn't be
considered official.)
Sorry about this. I was trying to make a difference bw pre-released
on my web site, and really released on GNU site. Maybe that was wrong
:(
23 matches
Mail list logo
