I have a few "antique" computers. The first Compaq, A very early
Sun SPARC 1. a Mac before they offered a hard drive and others
Had a VAX too, but no place to store it and some guy offered me
$1,500 for the tape drive...
These machines are only worth keeping if you still have the old
software t
>>> "Raphaël" == Raphaël Poss <[EMAIL PROTECTED]> writes:
Raphaël> I suffer with Autoconf/Automake when
Raphaël> looking for the correct include path to find Python C
Raphaël> interface headers. Could something be done about this
Raphaël> ?
Hi Raph!
See the end of
http://article.gmane.org/g
> On Thu, 20 Feb 2003 23:46:53 +0100, =?iso-8859-1?q?Rapha=EBl?= Poss
><[EMAIL PROTECTED]> said:
> This is a feature request.
> I have been writing several SWIG interfaces for a while, and I
> suffer with Autoconf/Automake when looking for the correct include
> path to find Python C interfac
This is a feature request.
I have been writing several SWIG interfaces for a while, and I suffer
with Autoconf/Automake when looking for the correct include path to
find Python C interface headers. Could something be done about this ?
Cheers,
--
/---
thanks! I'd been reading the 1.7.2 manual... Its all working for me now.
On Thu, 20 Feb 2003, Alexandre Duret-Lutz wrote:
> >>> "mcmahill" == mcmahill <[EMAIL PROTECTED]> writes:
>
> [...]
>
> mcmahill> The problem I'm having is that the lex source
> mcmahill> includes a header generated
>>> "Simon" == Simon Richter <[EMAIL PROTECTED]> writes:
[...]
>> (*) I'm assuming _LIBRARIES and _LTLIBRARIES have been merged
>> first.
Simon> ... since jars would be an exception then, since they
Simon> are not built with libtool as all other libraries are.
Sorry, the plan is *not* to al
Alexandre,
[Option 1: .jar files are libraries; Option 2: .jar files are archives]
> Eiter ways, even both together, sound fine to me. The former
> seems a lot simpler to implement (*), but if you are
> volunteering to implement the second...
Well, #2 seems a bit cleaner to me, especially...
>
Sorry for the delay.
>>> "Simon" == Simon Richter <[EMAIL PROTECTED]> writes:
[...]
Simon> The question is basically: Should jar files be treated
Simon> as libraries, losing the ability to stuff application
Simon> data into them, or should they be treated as
Simon> to-be-implemented archives
>>> "Paul" == Paul F Kunz <[EMAIL PROTECTED]> writes:
Paul> I have an application based on Qt that I build with automake on
Paul> Linux and other UNIX platforms. Now I'm attempting to build it on
Paul> Mac OS X. After I upgrade to libtool 1.4.3, I can build the
Paul> application, even with
>>> "JG" == Jean-Guillaume Paradis (LMC) <[EMAIL PROTECTED]> writes:
[...]
JG> dsiSecManager_SOURCES = file1.cpp $(PROJECT_ROOT_DIR)/include/file1.h
BTW, Automake doesn't support variables as *part of* filenames.
This break the dependency tracking code.
So, I you ever want to do this, it shoul
Hi Guido!
>>> "gd" == Guido Draheim <[EMAIL PROTECTED]> writes:
[...]
gd> there is no way that a path can be added - the aclocal 1.7
gd> does read $datadir/aclocal/dirlist but that one is a
gd> sysadmin file as well, not a user-home related file.
One workaround is to install aclocal in you
>>> "Bob" == Bob Rossi <[EMAIL PROTECTED]> writes:
[...]
Bob> I would like to create 1 library even though the sources are spread out
Bob> over 3 directories. I can only seem to come up with 2 undesirable solutions.
Bob> 1. Put all the code in one directory and make 1 library.
Bob> 2. Create
>>> "Martin" == Martin MOKREJ© <[EMAIL PROTECTED]> writes:
[...]
Martin> Unfortunately, I cannot find out where is the logfile of the test
Martin> executions to inspect details. The documentation on this is very bad:
Martin> http://www.gnu.org/manual/automake/html_mono/automake.html#SEC96 , so
>>> "mcmahill" == mcmahill <[EMAIL PROTECTED]> writes:
[...]
mcmahill> The problem I'm having is that the lex source
mcmahill> includes a header generated by yacc but the automake
mcmahill> generated makefile doesn't capture that dependency.
The 1.7.3 documentation has a paragraph about this
We're pleased to announce the release of Automake 1.7.3
This is a bug fix release. The list of bug fixes is appended.
You can find the new release here:
ftp://ftp.gnu.org/gnu/automake/automake-1.7.3.tar.bz2
ftp://ftp.gnu.org/gnu/automake/automake-1.7.3.tar.gz
ftp://sources.redhat.com
Olaf> Hello automake team,
Olaf> I'm using
Olaf> AM_INIT_AUTOMAKE([foreign 1.5 no-define dist-bzip2])
Olaf> which will create a tar.gz and tar.bz2 dist. How can I prevend
Olaf> automake from building the tar.gz dist, since there isn't a
Olaf> target like no-gzip-dist.
By submitting a patc
16 matches
Mail list logo
