> "Michael" == Michael Sweet <[EMAIL PROTECTED]> writes:
> Alexandre Oliva wrote:
>>
>> On Jan 22, 2001, Michael Sweet <[EMAIL PROTECTED]> wrote:
>>
>> > What it doesn't do (yet) is provide a tool to automate the creation
>> > of the list file.
>>
>> make install DESTDIR=/tmp/install
>> fi
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
> Due to security concerns, you're obviously never going to be able to
> install files owned by root without root privledges, but are you really
> telling me that these systems require you to _build_ packages as root?
Yes, this is normal
Has anybody looked at (epm) Easy Package Manager (http://www.easysw.com/epm/?
>From the FAQ:
--
It is a simple tool that generates software and patch distributions in
various formats, including:
AT&T Software Packages ("pkg"), used by Solaris.
Debian Package Manager ("dpkg")
HP-UX Software Pac
> "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
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Dec 18, 2000, Ganesan Rajagopal <[EMAIL PROTECTED]> wrote:
>> Okay, I understand. How about just excluding *only* the CVS
>> directories?
> And how about SCCS, RCS a
>>>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>>>>> "Ganesan" == Ganesan Rajagopal <[EMAIL PROTECTED]> writes:
Ganesan> When you provide Automake 1.4 a directory name to EXTRA_DIST
Ganesan> it slurps in the entire di
Hi,
When you provide Automake 1.4 a directory name to EXTRA_DIST it slurps in
the entire directory into the distribution including any CVS
directories. This is strictly not a bug as per the documentation but makes
the feature rather useless. Can we fix this to exclude CVS subdirectories
and back
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> The problem is that when it's time to link against the C++
Lars> library in the parent project, a C linker is chosen, which fails
Lars> on a lot of platforms (IRIX is one of them).
