[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please drop the ^main^ thing

This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.

From: Abdulaziz Ghuloum <aghuloum@xxxxxxxxx>
Subject: Re: Please drop the ^main^ thing
Date: Sat, 26 Sep 2009 09:10:23 +0300

> On Sep 26, 2009, at 5:18 AM, Shiro Kawai wrote:
> > If the library is untarred somewhere else
> > and 'make install'ed, auxiliary files can be left in the
> > untarred site (or 'make install' puts them in different
> > place).
> If you have a package manager, then it's not a problem,
> except that you cannot run files directly from the sources
> directory.  You always have to install then run.  Right?

Yes.  But the discussion shifted to assume there are enough
demand that packages may be just untarred directly under
a directory in the search path. 

> If you have a package "Acme Foo" that has the libraries you
> listed above, there are two options:
> With the implicit main, you get
> (acme foo)         => acme/foo/main.sls
> (acme foo helper1) => acme/foo/helper1.sls
> ...
> E.g., everything under a single directory.
> If we don't have an implicit main, you'd have to get:
> (acme foo)         => acme/foo.sls
> (acme foo helper1) => acme/foo/helper1.sls
> ...
> E.g., there are files under "acme" and files under "acme/foo".

Nah, the discussion is like this.  Suppose there are two

Sample package 1:
  Your package have sources for (acme foo),
  (acme foo helper1), (acme foo helper1 auxutil) and README.
Sample package 2:
  Your package have single source for (acme bar) and README.

Then files may be expanded to:

"Everything under a single directory" policy:

  package 1:

  package 2:

Not much here to confuse, right?

"No implicit main policity":

  package 1:
     acme/foo/README  ? maybe...

  package 2:
     ... where to put README?  create bar subdir *just* for README? ...

> I feel stronger towards the second, leaving it to Andreas's
> package manager to deal with the first.

Yeah, "we'll have smart package manager that deal with mess"
is one solution.  But I do understand Derick's concern;
relying on extra software component, which isn't even built,
doesn't seem a good practice.   "Untar under a search path"
will be guaranteed to work with minimum requirement.
(I personally think 'make' is a safe bet, but opinions vary.)