Re: automake and i18n
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 5.004 is sufficient for libintl-perl. Comments? Do you know any maintainer that does not know English? In other words, what's the use? Will you translate the documentation too? Why are other GNU developer packages like make or gcc internationalized? Because they are already heavily documented elsewhere. The two precise examples you chose are GNU versions of world wide spread utilities. But I hear your point, I just beg to differ on the relative importance. And I'm waiting for requests to internationalize configure, and the messages embedded in the Makefile rules :)
distcheck failure: version.texi
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 successful ../configure from automake-1.7i/_build ] Making all in doc make[2]: Entering directory `/home/ralf/automake/build/automake-1.7i/_build/doc' Updating ../../doc/version.texi cp: cannot create regular file `../../doc/version.texi': Permission denied make[2]: *** [../../doc/stamp-vti] Error 1
Re: automake and i18n
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 http://mail.gnu.org/archive/html/automake/2003-11/msg00046.html Bruno
Re: moving po/Makefile.in.in to automake
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 helped a lot. Here you go the opposite way, and I do not understand why. The separate po/LINGUAS has two reasons: - It's a place the store the set of languages other than in configure.ac (doesn't fit there for packages with multiple po/ directories) and in po/Makefile.in.in (which is usually copied from gettext without modifications). - It allows late addition of translations by a Linux distributor, as a drop-in into an already released package. For the other customizations there is no real need to put them into separate files. And since in most directories, all build-relevant settings are found in a Makefile.am, it's hard to learn for newbies why it should be different in po/ directories. With your new scheme, one has to re-run Automake and friends when a file is marked as containing translatable strings. Yes. Marking a file as containing translatable strings is a task performed by a package's maintainer, and it's allowed to require an automake run. Actually when the maintainer adds the file to xyz_SOURCES in Makefile.am, it also forces an automake invocation. Also did you talk to GNOME folks? Intltool accepts some extra markup in po/POTFILES.in (e.g. file type or encoding), and thus my guess is that they prefer a separate file. They prefer a separate file because the current po/Makefile.in.in mechanism doesn't permit them to do it another way. Extra flags for xgettext can always be accomodated through Makefile.am variables. Bruno
Re: Newbie Request for Help (make dist problem)
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 Scott platform specific is therefore in the top level directory). Automake assumes that your top-level directory will have a Makefile.am... Scott However, the problem lies Scott when trying to make dist. It copies all of the include, src and extra Scott directories into the build directory and only makes a tar.gz of the Scott files that were originally in the build...src directory (i.e. configure, Scott configure.ac, etc.). None of the source files make it into the Scott archive. Why is this happening? This is fallout from that assumption. Scott Additionally, it seems I would also Scott need to put the header files into the distribution, so I added: Scott EXTRA_DIST = \ Scott$(ISRC)/header1.h \ Scott$(SSRC)/header2.h 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. Tom
Re: Non-recursive make maintenance issue
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 single Makefile from multiple Makefile.am's in Jirka subdirectories. (Just kidding. But interested in seeing the reasons Jirka why this is nearly impossible.) 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 :-) Tom
Re: Help Requests
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 implies high (but one-time) rework cost. 2/ is best for diagnosing the problem further, as an eventual stepping-stone to 1/. wrt turn-around-time for responses, you can probably expect to find a huge variance even among the same people. e.g., sometimes i don't respond to mail for months or years... thi
Re: SUBDIRs and slashes
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 Marty directories in recursive make... adl I can't think of any. Back in the day there were two problems. First, automake's dist rule was not robust if there was a gap in the hierarchy. Second, autoconf wouldn't properly create intermediate directories in this same situation. I don't know whether either of these is still true today. The first one in particular has probably changed, I think I'm remembering our first dist implementation :-) Tom
Re: Non-recursive make maintenance issue
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 apps/build-postgres/src/build-postgres_SOURCES ? Yeah, that does seem easier. One problem is that you might refer to these variables elsewhere in your Makefile, and it isn't clear that automake can reliably rewrite all uses. If the user is able to define a formal synonym for the path, then this synonym can be used everywhere but in the synonym definition itself. That should ensure that automake has no difficulties and it allows the user to write a more compact Makefile.am. All automake needs is a unique way to identify the target. The initial reason for canonicalizing macro names was simply that automake was pretty dumb, and passed through its input directly to its output. Rewriting wasn't really possible. Exactly. Automake is much more powerful these days. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Non-recursive make maintenance issue
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 seem easier. One problem is that you might refer to these variables elsewhere in your Makefile, and it isn't clear that automake can reliably rewrite all uses. The initial reason for canonicalizing macro names was simply that automake was pretty dumb, and passed through its input directly to its output. Rewriting wasn't really possible. Tom
C programs using C++ libraries
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 discussed before on this list [1] and solutions given. I could build a dummy.cc to force C++ linking, I could use my own program_LINK, or I could do some magic with setting CCLD or similar. I have a few questions, please let me know if there is a better forum for them: 1. Why does my program need to be linked with a C++ compiler in some cases and not in others? Shared libraries should bring in their own dependencies, or libtool should find them, no? Is something broken with how the library is built? 2. I use libtool (but I do not understand why I use it). Is the following correct for my program_LINK command if I use libtool: program_LINK = $(LIBTOOL) --mode=link $(CXX) $(AM_CFLAGS) $(CFLAGS) \ $(AM_LDFLAGS) $(LDFLAGS) -o $@ 3. Who defines CXXLD and how? I have seen this variable referenced, it looks like I should use it above (to match CCLD), but nothing seems to define it. Is it obsolete? Thanks for your help, -Billy [1] http://mail.gnu.org/archive/html/automake/2002-11/msg00046.html
Re: Help Requests
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/ $(srcdir) I gave #2 a try, and it didn't change the output of make dist. However, 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 subdirectories away from the source files). I'll speak to the powers that be and see about getting this changed. Thanks again. wrt turn-around-time for responses, you can probably expect to find a huge variance even among the same people. e.g., sometimes i don't respond to mail for months or years... Thanks, I'll keep this in mind. Best Regards, Scott signature.asc Description: This is a digitally signed message part
Re: Newbie Request for Help (make dist problem)
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 Regards, Scott signature.asc Description: This is a digitally signed message part
Re: Non-recursive make maintenance issue
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 -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: distcheck failure: version.texi
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 the change from 2003-11-08 caused this, but as I don't Ralf understand all the implications, I won't suggest a fix. I've run distcheck successfully at least 4 times since that date (in order to upload the betas), so I'm quite surprised. Maybe a specific combination of timestamps is required? Could you post a link to a tarball of your files with instructions how to reproduce the problem from it? -- Alexandre Duret-Lutz
Re: Help Requests
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 in your source tree. /// didier Le mar 09/12/2003 21:19, J. Scott Amort a crit : 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/ $(srcdir) I gave #2 a try, and it didn't change the output of make dist. However, 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 subdirectories away from the source files). I'll speak to the powers that be and see about getting this changed. Thanks again. wrt turn-around-time for responses, you can probably expect to find a huge variance even among the same people. e.g., sometimes i don't respond to mail for months or years... Thanks, I'll keep this in mind. Best Regards, Scott
Re: Help Requests
... 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 subdirectories away from the source files).
Drat. I'm in *exactly* the same boat. I can't get 'make dist' to work
with relative paths, and my colleagues will go ballistic if I 'pollute'
the source tree with *NIX config files. I was hoping there was a magic
fix. :-{
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 work with my setup. Or is the
config files must be in the top-level dir rule so ingrained into the
tool that this is extremely unlikely?
Re: Help Requests
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 work with my setup. Or is the config files must be in the top-level dir rule so ingrained into the tool that this is extremely unlikely? I don't believe that the config files need to be in the top level directory. You can place those elsewhere since Autoconf Automake can be told where to find the tools. The only claim I have seen is that the top Makefile.am/Makefile.in has to be at the top of the source tree. That only makes for two files in the top directory, for a total of three once the source tree is configured. If you are exceedingly lazy, you might want to look for a new line of work. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C
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 only uses these for headers, but some other project might compile from .class to .o -- if they use an inner class, pow. Tom
Re: C programs using C++ libraries
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 the correct solution is. This has been discussed before on this list [1] and solutions given. I could build a dummy.cc to force C++ linking, I could use my own program_LINK, or I could do some magic with setting CCLD or similar. I have a few questions, please let me know if there is a better forum for them: 1. Why does my program need to be linked with a C++ compiler in some cases and not in others? Shared libraries should bring in their own dependencies, or libtool should find them, no? Is something broken with how the library is built? Operating system support varies regarding embedded dependency information in shared libraries, so depending on that feature is not portable. Libtool would help handle library dependencies if the problem library was linked using libtool, since then there would be a .la file associated with the library which includes the known library dependencies. Besides library dependencies, C++ code may also have different program intialization requirements (e.g. to support static construction, destruction, and exceptions) so a different startup module (the code that eventually invokes main()) may be supplied by the compiler. 2. I use libtool (but I do not understand why I use it). Is the following correct for my program_LINK command if I use libtool: program_LINK = $(LIBTOOL) --mode=link $(CXX) $(AM_CFLAGS) $(CFLAGS) \ $(AM_LDFLAGS) $(LDFLAGS) -o $@ This seems to be from an Automake generated Makefile. Are you using Automake? Passing the C++ compiler as the tool to use for linking seems reasonable. 3. Who defines CXXLD and how? I have seen this variable referenced, it looks like I should use it above (to match CCLD), but nothing seems to define it. Is it obsolete? I believe that this is a definition generated by the AC_PROG_LIBTOOL autoconf macro. If you are not including libtool with your package, then this macro won't be defined. If you are embedding libtool in your package, then you should definitely include AC_PROG_LIBTOOL in configure.ac. Thanks for your help, -Billy [1] http://mail.gnu.org/archive/html/automake/2002-11/msg00046.html == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: C programs using C++ libraries
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? Shared libraries should bring in their own dependencies, or libtool should find them, no? Is something broken with how the library is built? Operating system support varies regarding embedded dependency information in shared libraries, so depending on that feature is not portable. Libtool would help handle library dependencies if the problem library was linked using libtool, since then there would be a .la file associated with the library which includes the known library dependencies. Besides library dependencies, C++ code may also have different program intialization requirements (e.g. to support static construction, destruction, and exceptions) so a different startup module (the code that eventually invokes main()) may be supplied by the compiler. OK, this makes sense, so this establishes that I should use a C++ compiler to link my program, now it's just a question of how. 2. I use libtool (but I do not understand why I use it). Is the following correct for my program_LINK command if I use libtool: program_LINK = $(LIBTOOL) --mode=link $(CXX) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@ This seems to be from an Automake generated Makefile. Are you using Automake? Passing the C++ compiler as the tool to use for linking seems reasonable. I am using automake (hence why I posted to the automake list). I want to make sure that this is the 'correct' way to do this though, I find it scary to redefine the full link command like this when all I want to do is change the linker from using CCLD to CXX. 3. Who defines CXXLD and how? I have seen this variable referenced, it looks like I should use it above (to match CCLD), but nothing seems to define it. Is it obsolete? I believe that this is a definition generated by the AC_PROG_LIBTOOL autoconf macro. If you are not including libtool with your package, then this macro won't be defined. If you are embedding libtool in your package, then you should definitely include AC_PROG_LIBTOOL in configure.ac. I included AC_PROG_LIBTOOL in my configure.ac, along with AC_PROG_CXX and AC_LANG([C++]) yet none of this seems to get me CXXLD. $ libtool --version ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.25 2003/08/01 19:08:35) Debian: 49 $ $ autoconf --version autoconf (GNU Autoconf) 2.57 Thanks again, -Billy
automake distclean bug?
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 the result of an Automake bug. Is it possible that Automake 1.7.9 does not remove its distribution file via the 'distclean' target? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Current versions of automake and autoconf
(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 :( It turns out that a beta, even if you emphasize the need to test it, is not tested as thoroughly as a real release. So I was finally quite happy with having a (pre-)release spread in our community first, then have some real feedback before making the real release. This caught a couple of weak releases by the past, but I realize that this releasing scheme is a bit obscure. Unfortunately it relied on this obscurity: it is important, if you want some real feedback, that many people use it as a real release. So if I flag it as a pre-release, I doubt it will be tested as thoroughly :( In the future I'll try to be clearer. And I'm open to suggestions on how to improve the feedback on Autoconf :)
