Please drop the ^main^ thing
Abdulaziz Ghuloum
(25 Sep 2009 00:21 UTC)
|
Re: Please drop the ^main^ thing
Derick Eddington
(25 Sep 2009 18:23 UTC)
|
Re: Please drop the ^main^ thing
Derick Eddington
(25 Sep 2009 19:37 UTC)
|
Re: Please drop the ^main^ thing
Derick Eddington
(25 Sep 2009 19:42 UTC)
|
Re: Please drop the ^main^ thing
Derick Eddington
(25 Sep 2009 19:40 UTC)
|
Re: Please drop the ^main^ thing
Derick Eddington
(25 Sep 2009 19:47 UTC)
|
Re: Please drop the ^main^ thing
Abdulaziz Ghuloum
(26 Sep 2009 08:37 UTC)
|
Re: Please drop the ^main^ thing
Shiro Kawai
(25 Sep 2009 19:59 UTC)
|
Re: Please drop the ^main^ thing
Andreas Rottmann
(25 Sep 2009 20:33 UTC)
|
Re: Please drop the ^main^ thing
Derick Eddington
(25 Sep 2009 22:04 UTC)
|
Re: Please drop the ^main^ thing
Derick Eddington
(26 Sep 2009 01:16 UTC)
|
Re: Please drop the ^main^ thing
Derick Eddington
(25 Sep 2009 21:02 UTC)
|
Re: Please drop the ^main^ thing
Shiro Kawai
(25 Sep 2009 22:07 UTC)
|
Re: Please drop the ^main^ thing
Derick Eddington
(26 Sep 2009 01:07 UTC)
|
Re: Please drop the ^main^ thing
Shiro Kawai
(26 Sep 2009 02:16 UTC)
|
Re: Please drop the ^main^ thing
Abdulaziz Ghuloum
(26 Sep 2009 06:10 UTC)
|
Re: Please drop the ^main^ thing
Shiro Kawai
(26 Sep 2009 07:59 UTC)
|
Re: Please drop the ^main^ thing
Abdulaziz Ghuloum
(26 Sep 2009 08:14 UTC)
|
Re: Please drop the ^main^ thing
Derick Eddington
(27 Sep 2009 03:26 UTC)
|
Re: Please drop the ^main^ thing Shiro Kawai (27 Sep 2009 04:59 UTC)
|
Re: [OT] English
Derick Eddington
(27 Sep 2009 05:29 UTC)
|
>From: Derick Eddington <xxxxxx@gmail.com> Subject: Re: Please drop the ^main^ thing Date: Sat, 26 Sep 2009 20:26:38 -0700 > > I meant the latter. 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). But if we just want to untar directly under library > > path, then I'd prefer a library package expands into a single > > directory, under their library name's last symbol. E.g. > > if a package provides (acme foo) (acme foo helper1) (acme foo helper2), > > everything is under acme/foo/, including README. > > So the files for those libraries must be(?): > > acme/foo/^main^.sls > acme/foo/helper1/^main^.sls > acme/foo/helper2/^main^.sls > > because "libraries' files are required to be under their library name's > last symbol". Oops, sorry, I confused libraries and packages. I assume auxiliary files are per packages, so what's required is that "everything in package expands inside one directory specific to the package". So sub-libraries in a package don't need implicit file. acme/foo/^main^.sls acme/foo/helper1.sls acme/foo/helper2.sls acme/foo/README > > I guess nothing is bad except weird feeling. On the other > > hand, I don't need to name my C program entry point to > > int ^main^(int, char**) or int MAIN(int char**) or something > > that stands out. I trained to spot "main" specially. > > Another reason I don't like using "main" for the implicit file name is > that I think libraries named (--- main) are not so uncommon that they > should have to be named "---/_main.sls" or "---/main/main.sls" I don't see it so much problem, better than having ^main^, but opinions vary... > > > But that means you can never put a > > > (foo main) library in the "foo" directory, which I don't like. > > > > This part I didn't get. Can you explain in examples? > > Say you have libraries (foo bar) and (foo main) and you want their files > to both be in (not just under) the "foo" directory -- you can't do that > because, by the rule you mentioned, (foo main) must go in > "foo/main/main.sls". I want to support the ability to use or not use > the implicit file name. Ah I see; "in 'foo'" means "directly under 'foo', not in a subdirectory of 'foo'". English is difficult. After all, I feel that my opinions are not very strong. So my position is: - A package untars into single package directory may be desired. -- this means some sort of implicit filename is required. - ^main^ looks just a little bit too ugly to me. but I don't have alternatives that are technically better. --shiro