zsh-workers
 help / color / mirror / code / Atom feed
From: DervishD <zsh@dervishd.net>
To: Peter Stephenson <pws@csr.com>
Cc: zsh-workers@sunsite.dk
Subject: Re: zshall.1
Date: Mon, 24 Oct 2005 14:33:47 +0200	[thread overview]
Message-ID: <20051024123347.GC355@DervishD> (raw)
In-Reply-To: <20051024130020.341f1235.pws@csr.com>

    Hi Peter and Zvi :)

 * Peter Stephenson <pws@csr.com> dixit:
> "Zvi Har'El" <rl@math.technion.ac.il> 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...


  reply	other threads:[~2005-10-24 12:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-24  8:01 zshall.1 Zvi Har'El
2005-10-24  9:03 ` zshall.1 Peter Stephenson
2005-10-24 11:52   ` zshall.1 Zvi Har'El
2005-10-24 12:00     ` zshall.1 Peter Stephenson
2005-10-24 12:33       ` DervishD [this message]
2005-10-24 13:01         ` zshall.1 Peter Stephenson
2005-10-24 13:34         ` zshall.1 Peter Stephenson
2005-10-24 13:55           ` zshall.1 DervishD
2005-10-24 13:30       ` zshall.1 Clint Adams
2005-10-24 14:58   ` zshall.1 Bart Schaefer
2005-10-24 16:05     ` zshall.1 DervishD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051024123347.GC355@DervishD \
    --to=zsh@dervishd.net \
    --cc=pws@csr.com \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).