>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
adl> [...]
Tom> If there is no vendor install program, autoconf will choose
Tom> install-sh. The path to install-sh might be a relative path, because
Tom> $srcdir might be relat
> > Are there several issues here?
> >
> > The package maintainer has the package to worry about.
>
> Aha! Here's the crossed wire. What I was envisioning was a package tool
> designed such that most platforms wouldn't _need_ devoted package
> maintainers .
We're using different language. For
> "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
Michael Sweet wrote:
> Rusty Ballinger wrote:
> > ...
> > (What packaging systems only let you create packages as root, and
> > why do they do that? I know rpm *wants* you to be root, but you
> > don't have to be...)
>
> Debian's dpkg needs you to run as root; otherwise the files you
> install w
Harlan Stenn wrote:
> Are there several issues here?
>
> The package maintainer has the package to worry about.
Aha! Here's the crossed wire. What I was envisioning was a package tool
designed such that most platforms wouldn't _need_ devoted package maintainers.
A single package maintainer usi
> I'm getting into this discussion a little late, but here are my
> $0.02.
>
> First, see:
>
> http://www.easysw.com/epm
>
> and specifically:
>
> http://www.easysw.com/epm/epm-paper.html
Yes, actually I have looked at it. I'm using it to build the packages in
my project right now.
Rusty Ballinger wrote:
> ...
> (What packaging systems only let you create packages as root, and
> why do they do that? I know rpm *wants* you to be root, but you
> don't have to be...)
Debian's dpkg needs you to run as root; otherwise the files you
install will be owned by your user & group.
H
> > 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
Pavel Roskin wrote:
> ...
> not as root. GNU tar cannot be tricked into hardcoding the ownership
> different from the actual ones (as far as I know).
> ...
Also, you can't map the filenames/directories, e.g.:
filename.c -> project-major.minor/filename.c
program -> /usr/bin/program
--
_
Hi,
Pavel Roskin <[EMAIL PROTECTED]> writes:
[snip]
> 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'
Hello, Geoffrey!
> Anyway, here's some of my thoughts about it:
> 1) written in Python
In case you ever change you mind, there is an implementation of tar
written entirely in Perl:
http://www.cpan.org/modules/by-module/Archive/
This module may be very valuable for you if you want to create pac
Are there several issues here?
The package maintainer has the package to worry about.
Another "hat" might wrap packages for installers, including templates for a
variety of sources (like RPMs, the FreeBSD ports collection, etc).
The last "hat" would take these packages, possibly build them, and
Akim> I'll investigate where this is coming from. Can it be sufficient?
Yes.
Tom
Lars> I know I can override check-TESTS, but I'd prefer not to.
What do you need to do this for?
One way to do your own checking is `check-local'.
I guess we could add `check-hook'.
If you need a particular file built then you can use `check_DATA'.
Tom
"Derek R. Price" wrote:
> ...
> I'm still thinking a two stage process is in order: A script that
> scrapes the Makefile and a meta spec file (since the make process
> is invoking it this could simply mean it is passed the appropriate
> data) to create the package manager specific spec file and a
Geoffrey Wossum wrote:
> > You can use GNU m4 or PERL in autoconf and automake, as these are
> > maintainer-only tools. If autopackage is a package-installer tool (i.e. a
> > native package front-end) the choice of implementation language is almost
> > restricted to "/bin/sh" or "/bin/sh" and pro
> I think this need to depend on the configure-generated Makefile will have a
> very constraining effect on the implementation language: this precludes
> using ANYTHING that's not installed standard on any of the expected target
> OSes... That's exactly why configure generates sh-scripts and why l
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> I don't know why. Does configure AC_SUBST(CXX)?
/tmp/fileutils-4.0.37 % fgrep CXX configure nostromo 20:03
s,@CXXFLAGS@,$CXXFLAGS,;t t
I'll investigate where this is coming from. Can it be sufficient?
> On Mon, 22 Jan 2001 11:41:50 -0700, Tom Tromey <[EMAIL PROTECTED]> said:
> You can probably do it by hand:
>foo_DATA = my.jar
>my.jar: $(my_java_sources) ...
Works, Thanks (stupid mistake on my part kept it from working
before I posted to the list).
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> (iii): why the heck does automake include CXX related macros in
Akim> the fileutils Makefile.ins??? This is very confusing to
Akim> autoscan, and frankly, I don't think this is good.
I don't know why. Does configure AC_SUBST(CXX)?
> "Paul" == Paul F Kunz <[EMAIL PROTECTED]> writes:
Paul> I'm trying to get automake to build a Makefile that will update
Paul> the project's `.jar' file whenenver any `.java' files get
Paul> compiled. No success so far. Can someone give me a solution to
Paul> this?
Unfortunately there isn
>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
[...]
adl> + # don't count orphan right brackets
adl> + $depth = 0 if $depth < 0;
Tom> How important is this?
Peanut. But since I was going to mimic m4, it doesn
>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
[...]
Tom> If there is no vendor install program, autoconf will choose
Tom> install-sh. The path to install-sh might be a relative path, because
Tom> $srcdir might be relati
> > I'm looking for a way to run a specific target before check-TESTS.
>
> check: your-target
> your-target:
> do whatever you want
>
> If you really mean check-TESTS, use that instead of check.
D'oh. Why did this not work before I posted, but it works now??
Thanks!
On Jan 22, 2001, Lars Hecking <[EMAIL PROTECTED]> wrote:
> I'm looking for a way to run a specific target before check-TESTS.
check: your-target
your-target:
do whatever you want
If you really mean check-TESTS, use that instead of check.
--
Alexandre Oliva Enjoy Guarana', see http:
I'm looking for a way to run a specific target before check-TESTS.
Both the local and the hook method (the latter doesn't support check,
btw) run the specified target after check-TESTS.
I know I can override check-TESTS, but I'd prefer not to.
"Derek R. Price" wrote:
> Akim Demaille wrote:
>
> > VPATH is just set to srcdir? So then, I'm in favor of Derek's patch
> > which seems finer that the current one, and updating the Autoconf
> > documentation to explain exactly what happens.
>
> Here's an even slightly better version. It will r
Akim Demaille wrote:
> So, I think I'm slowly starting to understand this VPATH stuff:
> configure wants to remove it only when useless, right? I.e., when
> VPATH is just set to srcdir? So then, I'm in favor of Derek's patch
> which seems finer that the current one, and updating the Autoconf
>
> -Original Message-
> From: Derek R. Price [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 19, 2001 10:36 PM
> To: [EMAIL PROTECTED]
> Cc: Geoffrey Wossum; [EMAIL PROTECTED]
> Subject: Re: More an autopackage
>
>
> Tom Tromey wrote:
>
> > Unfortunately, I don't think it is that easy
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> It seems to me that Autoconf's job is not to remove unportable
Akim> code written by the user, so it seems wrong to have it remove
Akim> VPATH definitions from Makefiles. Histori
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> Should [trasnform] be quoting the substitution string in each
Tom> case?
According to its current uses, I'd say so. Both the lhs and rhs.
I must say I also saw some places where /o was used. I have no idea
if it applies here. I don't
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Akim> * vtexi.test: Also check that stamp-vti properly depends upon
Akim> configure.in and the Texinfo source file.
Tom> This is ok.
Akim> +set -e
Tom> I usually use explicit `|| exit 1' after commands. But it
Tom> probably doesn't matter.
Actually, I'd like to apply this patch anyway, since the following
patches are making it more useful. Let me show you what it does when
all the patches are applied:
/tmp/fileutils-4.0.37 % ../ace/autoscan -A ../ace nostromo 9:47
Name "main::args" used only once: possible typo at
33 matches
Mail list logo
