Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: zshall.1
- X-seq: zsh-workers 21921
- From: DervishD <zsh@xxxxxxxxxxxx>
- To: Peter Stephenson <pws@xxxxxxx>
- Subject: Re: zshall.1
- Date: Mon, 24 Oct 2005 14:33:47 +0200
- Cc: zsh-workers@xxxxxxxxxx
- In-reply-to: <20051024130020.341f1235.pws@xxxxxxx>
- Mail-followup-to: Peter Stephenson <pws@xxxxxxx>, zsh-workers@xxxxxxxxxx
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- Organization: DervishD
- References: <20051024080141.GA18213@xxxxxxxxxxxxxxxxxxxxxxxxxx> <EXCHANGE03dgpyIb84V00007ae6@xxxxxxxxxxxxxxxxxx> <5ed187370510240452l26ce144cyf23d0b3c7decf259@xxxxxxxxxxxxxx> <20051024130020.341f1235.pws@xxxxxxx>
Hi Peter and Zvi :)
* Peter Stephenson <pws@xxxxxxx> dixit:
> "Zvi Har'El" <rl@xxxxxxxxxxxxxxxxxxx> wrote:
> > I don't know better how people use it, but the usage has to be consistent.
> > If you install your zsh as zsh-dev, and man zsh-dev, man zsh-devoptions etc
> > all give you the new manual page, man zsh-devall should do the same!
>
> That wasn't quite the point...
>
> At least one of those prefix/suffix things was introduced so you
> could install zsh in one place (where it would never be used),
> package it up there, then have the package install it in the normal
> place. In other words, it would never be run in the place where it
> was actually installed, it always got moved first.
In autoconf, the program-prefix, program-suffix and
program-transform-name were introduced to modify the names of the
binaries, and in fact if this facility is used to install the
software into a temporary place to package it afterwards, then it
will not probably work (if you transformed DATADIR, for example).
If you want to install the software in a place suitable to make a
distribution package, then you should use the "DESTDIR" variable, at
least this is the common practice with autoconf-based software.
The real problem is that autoconf doesn't force the developer to
change the names even when program-whatever options are used. So
there is really NO WAY of telling if those options are intended to
modify installation names or to do packaging: the developer can use
it for both things (that's one of the million reasons why I wrote
MOBS for my projects).
If the options were called 'transform-names', 'add-prefix' and
'add-suffix', the intention would be much clearer, but with the
current name I wouldn't make a bet. Right now using those options is
very dangerous because, depending on the developer, they can apply
ONLY to binaries, they can apply only in the name level and not in
the code level (I mean, you install "myprogram" with a transformed
name of "myprogname-suffixed" and you don't know if it will look for
data in $datadir/myprogname or $datadir/myprogname-suffixed), or
probably you can only modify the $prefix so you can install it in any
directory to package it. There is no way of knowing.
What I would suggest here is to document the behaviour or simply
don't honoring any transformation and issue a warning if any is
provided. If zsh installation names can be modified, they have to be
consistently and allow documentation names to be modified
accordingly. Another, better solution, is to get rid of the autoconf
nightmare, but unfortunately there aren't many replacements out there
(and not, MOBS is not *exactly* an autotools replacement). The less
intrusive change may be to change ALL installation names (including
the hardcoded paths, if any, that zsh uses) when a transformation is
requested, and document this behaviour. Otherwise don't allow
transformations, if this will lead to less surprises to an advanced
end user (advanced in the sense of autoconf, not zsh).
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...
Messages sorted by:
Reverse Date,
Date,
Thread,
Author