Re: System configuration during install

David If possible, I would like to support the widest range of David systems possible with the constraint that I don't as yet David understand how they vary. I think most people handle this by writing a document for their project that says once `make install' is done, here is how you can

Re: override default CXXFLAGS

I set the CXXFLAGS via AM_CXXFLAGS in Makefile.am. the relase version should have no -g flag... but there is a default CXX_FLAGS variable in Makefile which has always the -g flag. how can I remove this one? One way is to set it in the environment when running the configure script: $

Re: interpolating automake variables?

Hey, I have a question about the interpolation of automake variables like pkglibdir, pkgdatadir, etc. The way to do it recommended in the GNU coding standards is to do it in Makefiles, not at configure-time, so that the user can override the setting of prefix, exec_prefix, etc, during

interpolating automake variables?

Hey, I have a question about the interpolation of automake variables like pkglibdir, pkgdatadir, etc. Suppose your package installs programs and scripts which need to know where to find your package's data files, and you want your documentation to have the full paths of your program, etc. The

Re: problem with make install and java

I'm using automake with mix C++ and Java code. Everything is fine, even the creating of JNI header files, except for one thing. On "make install", the .class files get copied into the installation directory. Since, I'm creating a .jar file, which gets installed in $prefix/share, I

Re: include only in cvs-automake?

Wow. I almost sent a message to say that I had definitely used `include' in some old (circa-1997) projects. But I dug out the code, and it seems I was relying on make's own include implementation. I am still using automake-1.4 (so that I can be certain that the upcoming libtool releases

Re: More an autopackage

Wouldn't Perl5 be a more widely acceptable choice? Considerably so? (Indeed, isn't automake already in Perl? Why choose something different? Especially when that something is considerably less widely installed?) Because Perl is almost unreadable and Python is a very nice language? No

Re: Package support (RPM, deb, pkg, kits, etc.)

There were two reasons I stopped doing this. One reason is that it isn't clear that this is needed. At least the Debian and RPM communities have already solved these problems to their satisfaction. I disagree in two ways: - As a developer who builds distributes packages, I'd love a tool

Re: [patch] libtoolize --acdir --ltdir

Did this patch go in to libtool? Not yet. Having it posted to the right mailing list ([EMAIL PROTECTED]) *might* help accelerating the process, since then other maintainers of libtool might look into it. Thanks; I just sent the libtoolize parts of the patch to that list. --Rusty

[patch] noinst_JAVA

Hey, a thing that's bothered me for a while is that noinst_JAVA is broken. If you use noinst_JAVA, your .java files are still assigned to noinst_JAVA, and clean-noinstJAVA removes classnoinst.stamp, but DIST_COMMON gets $(_JAVA) instead of $(noinst_JAVA), all-am depends on class.stamp instead of

libtoolize --acdir --ltdir?

It's nice that autoconf's --macrodir and automake's --amdir let you specify alternate directories to load files from. Unfortunately, when automake calls libtoolize, it appears that there's no way for it to tell libtoolize to use a different pkgdatadir or aclocaldir. One approach would be to add