Tom Tromey wrote:
> The idea behind DOCUMENTATION is to provide a way to install README
> and the other stuff that ends up (eg) in /usr/doc/$PACKAGE.
Just a note, I believe the RedHat standard is /usr/share/doc now.
Derek
--
Derek Price CVS Solutions Architect ( http://CVS
> "Michael" == Michael Still <[EMAIL PROTECTED]> writes:
>> lib_LIBRARIES = libfoo.a
>> devel_header_HEADERS = foo/foo.h
Michael> Why don;t you just have some different primaries? Like, for
Michael> instance:
Michael> rpm_PROGRAMS = foo
Michael> foo_SOURCES = foo.c wibble.c hamster.c
This
> "Ganesan" == Ganesan Rajagopal <[EMAIL PROTECTED]> writes:
Ganesan> I have been thinking about this too. Installable objects
Ganesan> should have a package prefix. We can also have a global
Ganesan> variable called PACKAGES or something like that, so that
Ganesan> automake can generate inst
On 13 Jan 2001, Alexandre Oliva wrote:
> On Jan 12, 2001, Michael Still <[EMAIL PROTECTED]> wrote:
>
> > Why don;t you just have some different primaries?
>
> The issue is not about having different programs depending on the
> packaging tool. It's about creating multiple binary packages, with
>
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 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
> 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
> "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,
I'm interested in platform dependent packaging support, such as RPM and
pkg and friends. The autotools book mentions support for these for 1.5,
but the CVS code doesn't show any work towards this goal. The TODO file
has this as a long term goal, mentioning possibly creating another tool
for
11 matches
Mail list logo
