On Jan 12, 2001, Michael Still <[EMAIL PROTECTED]> wrote:
> On 12 Jan 2001, Tom Tromey wrote:
>> The automake-related idea I had was that installable objects would be
>> marked by the sub-package they belong to. Something like:
>> lib_LIBRARIES = libfoo.a
>> devel_header_HEADERS = foo/foo.h
>
On Jan 12, 2001, Tom Tromey <[EMAIL PROTECTED]> wrote:
> Alexandre, if the most recent real libtool release still uses
> AM_PROG_LIBTOOL
The most recent releases of libtool have all accepted both. Maybe we
should disable the warning for a while, or trigger it only if
AC_PROG_LIBTOOL exists in a
On 12 Jan 2001, Tom Tromey wrote:
> I do think it would be useful. However it seems that most package
> maintainers are not also the package developers. And, most package
> maintainers only develop for a single platform.
I'm not sure this is true... I know for the software I write, I also
crea
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
> Anyway I think the big problem is sub-package breakdown. Maybe this
> is solveable. I'm willing to put patches into automake that help with
> `autopackage'.
> The automake-related idea I had was that installable objects would be
> marked
> "Rusty" == Rusty Ballinger <[EMAIL PROTECTED]> writes:
Rusty> - As a developer who builds & distributes packages, I'd love a
Rusty> tool which abstracts platform-specific packaging, the same way
Rusty> autoconf & automake abstract platform-specific building. I
Rusty> don't want to become a
> "Dave" == Dave Brolley <[EMAIL PROTECTED]> writes:
Dave> To work around the problem I have to change the generated dependency to:
Dave>h1.lo: ../host/h1.cpp
Dave>$(LTCXXCOMPILE) -c -o $@ $<
Dave> Is this a make bug, or should automake be generating a rule for
Dave> making hl.l
Sending configure.in as requested
Tom Tromey wrote:
>> "Dave" == Dave Brolley <[EMAIL PROTECTED]> writes:
>
>
> Dave> I have a project which contains a mix of C and C++ sources, and
> Dave> dependency tracking does not seem to be enabled. I've attached
> Dave> my Makefile.am and Ma
>> libtool --version
ltmain.sh (GNU libtool) 1.3.4 (1.385.2.196 1999/12/07 21:47:57)
Tom Tromey wrote:
>> "Dave" == Dave Brolley <[EMAIL PROTECTED]> writes:
>
>
> Dave> I installed the Real Millenium Beat (1.4b) on my Cygwin system
> Dave> (Windows 95). My configure.in uses AM_PROG_L
> 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
> "Dave" == Dave Brolley <[EMAIL PROTECTED]> writes:
Dave> I installed the Real Millenium Beat (1.4b) on my Cygwin system
Dave> (Windows 95). My configure.in uses AM_PROG_LIBTOOL and automake
Dave> complains that it is obsolete and that I should use
Dave> AC_PROG_LIBTOOL. Ok, so when I make t
> "Dave" == Dave Brolley <[EMAIL PROTECTED]> writes:
Dave> I have a project which contains a mix of C and C++ sources, and
Dave> dependency tracking does not seem to be enabled. I've attached
Dave> my Makefile.am and Makefile.in for reference. Just wobdering if
Dave> I'm missing something. I'
Hi,
One of the reasons I tried automake 1.4b was to see if the support for
compiling sources from other directories had been included. I was
delighted to see that some work has been done in this area. Using my
previous example, the directory structure is something like:
src/main -- most of th
> "Geoffrey" == Geoffrey Wossum <[EMAIL PROTECTED]> writes:
Geoffrey> Seeing as how packaging support doesn't seem to be here yet,
Geoffrey> I would like to work on it.
Geoffrey> 1) Is my evalution of automake's current lack of package
Geoffrey> support correct?
Yes.
Geoffrey> 2) Would it
Hi,
The automake online documentation says, regarding automatic dependency
tracking:
" this mode is enabled by default if any C program or library is
defined in the current directory"
I have a project which contains a mix of C and C++ sources, and
dependency tracking does not seem to be e
Hi,
I installed the Real Millenium Beat (1.4b) on my Cygwin system (Windows
95). My configure.in uses AM_PROG_LIBTOOL and automake complains that it
is obsolete and that I should use AC_PROG_LIBTOOL. Ok, so when I make
the change, autoconf (version 2.13) says that it can't find AC_PROG_LIBTOOL
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> I'm not sure why, but adding ansi2knr causes the file to be
Robert> listed in the dependencies for the target as:
Robert> FSD_Archive$U.lo
Robert> even though it is C++, and shouldn't be affected.
Robert> I'm no automake guru, so
> "Anna" == Anna Niemtschk <[EMAIL PROTECTED]> writes:
Anna> When I try to add AM_CONDITIONAL to configure.in I get:
Anna> configure: syntax error at line 3497: `AM_CONDITIONAL' unexpected
You have to run aclocal before running autoconf.
Tom
17 matches
Mail list logo
