> 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 y
> 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:
$ CXXF
> > 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, dur
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 wa
> What is the best way to have a script/program where $pkgdatadir is
> located?
>
> For C, it's easy enough just to do
> CCFLAGS=-DPKGDATADIR="\""$(pkgdatadir)"\"" but what about things like perl
> scripts that have to pull option files and such. Is there a standard way
> to tackle this?
There m
>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,
> 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 releas
> > This module may be very valuable for you if you want to create packages
> > not as root. GNU tar cannot be tricked into hardcoding the ownership
> > different from the actual ones (as far as I know).
>
> You can use 'fakeroot' (now called 'libtricks' I think) from Debian.
> It is essentially a
> > 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
> 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
> > 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
> > Hey, a thing that's bothered me for a while is that noinst_JAVA
> > is broken.
>
> Thanks, I checked in your patch.
One problem with the patch is that since the noinst_JAVA stuff is "noinst",
there's no install-data-am dependency on "install-noinstJAVA" or
classnoinst.stamp, so a "make instal
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
nd assume that Automake libtool support is used.
@@ -1934,6 +1939,11 @@
@item --help
Display a help message and exit.
+
+@item --ltdir=@var{dir}
+Look for libtool data files in directory @var{dir} instead of in the
+installation directory. If you use this, you may also want to use
+@code{--acdir}.
@item
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
15 matches
Mail list logo
