August 04, 2010
Michel Fortin wrote:
> As a side note, my D plugin for Xcode expects DMD to be available at /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in /usr/local/lib. It won't work if the files can't be found there, although I might change that if an official distribution of DMD installs itself elsewhere.

To me, the biggest problem is deciding where the files should go. There doesn't seem to be any consensus or culture in OS X about this.
August 04, 2010
Walter Bright wrote:
> Michel Fortin wrote:
>> As a side note, my D plugin for Xcode expects DMD to be available at /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in /usr/local/lib. It won't work if the files can't be found there, although I might change that if an official distribution of DMD installs itself elsewhere.
> 
> To me, the biggest problem is deciding where the files should go. There doesn't seem to be any consensus or culture in OS X about this.

Since we're talking about a Unix command-line utility, I suggest we go with the Unix traditional directories.

Andrei
August 04, 2010
Andrei Alexandrescu wrote:
> Walter Bright wrote:
>> Michel Fortin wrote:
>>> As a side note, my D plugin for Xcode expects DMD to be available at /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in /usr/local/lib. It won't work if the files can't be found there, although I might change that if an official distribution of DMD installs itself elsewhere.
>>
>> To me, the biggest problem is deciding where the files should go. There doesn't seem to be any consensus or culture in OS X about this.
> 
> Since we're talking about a Unix command-line utility, I suggest we go with the Unix traditional directories.

Which are what, for:

dmd
libphobos
phobos imports

?
August 04, 2010
Walter Bright, el  4 de agosto a las 12:41 me escribiste:
> Andrei Alexandrescu wrote:
> >Walter Bright wrote:
> >>Michel Fortin wrote:
> >>>As a side note, my D plugin for Xcode expects DMD to be available at /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in /usr/local/lib. It won't work if the files can't be found there, although I might change that if an official distribution of DMD installs itself elsewhere.
> >>
> >>To me, the biggest problem is deciding where the files should go. There doesn't seem to be any consensus or culture in OS X about this.
> >
> >Since we're talking about a Unix command-line utility, I suggest we go with the Unix traditional directories.
> 
> Which are what, for:

I'd say:

> dmd

/usr/local/bin

> libphobos

/usr/local/lib

> phobos imports

/usr/local/include/d (d is just a suggestion, since at least Debian/Ubuntu uses that, well, without the "local" because are official packages, for gdc and ldc).

And you may add /usr/local/etc as a search path for dmd.conf (and look for it *before* /etc is searched) and install dmd.conf there.

Main reference:
FHS: /usr/local Local hierarchy:
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY

Some other references:
FHS: http://www.pathname.com/fhs/pub/fhs-2.3.html
LSB: http://www.linuxfoundation.org/collaborate/workgroups/lsb (yes,
Linux only)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
3 people die every year, testing if a 9 volts battery works on their tongue
August 04, 2010
On 2010-08-04 15:31:32 -0400, Walter Bright <newshound2@digitalmars.com> said:

> Michel Fortin wrote:
>> As a side note, my D plugin for Xcode expects DMD to be available at /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in /usr/local/lib. It won't work if the files can't be found there, although I might change that if an official distribution of DMD installs itself elsewhere.
> 
> To me, the biggest problem is deciding where the files should go. There doesn't seem to be any consensus or culture in OS X about this.

I agree. It took me quite a while to decide to do things as I did. The goals were:

1. It should be easy to manually replace DMD from a new package from Digital Mars.
2. It should work on the command line with no user intervention (no need to add something to $PATH in the bash profile for instance).
3. It should not mess with the system directories.

Except when it come from third party package managers (fink, MacPorts), most Unix software not coming from Apple installs in /usr/local on Mac OS X (for instance I have: MySQL, Git, Mercurial, Doxygen, 7za and a couple others there). So it makes a lot of sense to install it there.

To make manual replacement easy, I wanted to preserve the dmd and dmd2 directories from the zip archive intact, so it's easy to swap them for another one. Initially, I decided to use /usr/local/dmd and /usr/local/dmd2, and add with symlinks in /usr/local/{bin,lib,man} to make everything work from the command line without changing $PATH.

Symlinks didn't work quite well: dmd takes the value of args[0] to know which directory to search for dmd.conf. I guess I could have installed a dmd.conf in /etc/ to override that, but then how do you install dmd1 and dmd2 side by side? So what I did is replace the symlinks with a sort of trampoline program that adjusts the value of the args[0] for the path of the DMD just before calling exec(), allowing a different dmd.conf to be used for each one.

And using /usr/local/{dmd,dmd2} wasn't entirely satisfactory either. Mac OS X hides the /usr folder when you browse using the Finder. So replacing /usr/local/{dmd,dmd2} manually with a newer one isn't as straightforward as it should be. I settled on using /Library/Compilers/{dmd,dmd2}. This isn't entirely satisfactory either since it doesn't follow UNIX ways, but it's not too far of how Mac OS X is packaged and I told myself it'd be easier to support users that way.

Now, the only missing piece for an easy manual replacement of DMD is a zip archive where the executable bit is set.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

August 04, 2010
On 2010-08-04 17:56:31 -0400, Leandro Lucarella <luca@llucax.com.ar> said:

> I'd say:
> 
>> dmd
> 
> /usr/local/bin

That makes a lot of sense. I agree that /usr/local/{bin,lib,man} is the right place.

But you can't install dmd1 and dmd2 side by side this way (because of dmd.conf). That's why the D for Xcode installer put them elsewhere and simply add symlinks in /usr/local/bin. (Or to be more precise: symlink-like programs that set args[0] to the real dmd path.)


>> libphobos
> 
> /usr/local/lib
> 
>> phobos imports
> 
> /usr/local/include/d (d is just a suggestion, since at least
> Debian/Ubuntu uses that, well, without the "local" because are official
> packages, for gdc and ldc).
> 
> And you may add /usr/local/etc as a search path for dmd.conf (and look
> for it *before* /etc is searched) and install dmd.conf there.

About dmd.conf: perhaps dmd2 should look for dmd2.conf instead of dmd.conf. This way you can have both dmd1 and dmd2 installed side by side.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

August 05, 2010
Michel Fortin wrote:
>> To me, the biggest problem is deciding where the files should go. There doesn't seem to be any consensus or culture in OS X about this.
> 
> I agree. It took me quite a while to decide to do things as I did. The goals were:
> 
> 1. It should be easy to manually replace DMD from a new package from Digital Mars.
> 2. It should work on the command line with no user intervention (no need to add something to $PATH in the bash profile for instance).
> 3. It should not mess with the system directories.

It used to be that /usr/local/bin wasn't in the $PATH, and that
the shell wasn't bash either for that manner. And since GDC was
using the GCC installation anyway, it installs into /usr/bin...
(while being relocatable to a root, like Developer/usr/bin too)

> Except when it come from third party package managers (fink,
> MacPorts), most Unix software not coming from Apple installs in
> /usr/local on Mac OS X (for instance I have: MySQL, Git, Mercurial,
> Doxygen, 7za and a couple others there). So it makes a lot of sense
> to install it there.

Yeah, as long as the user has admin privileges the /usr/local
hierarchy (and matching /Library) is definitely the one to use.

[...]
> And using /usr/local/{dmd,dmd2} wasn't entirely satisfactory either. Mac OS X hides the /usr folder when you browse using the Finder. So replacing /usr/local/{dmd,dmd2} manually with a newer one isn't as straightforward as it should be. I settled on using /Library/Compilers/{dmd,dmd2}. This isn't entirely satisfactory either since it doesn't follow UNIX ways, but it's not too far of how Mac OS X is packaged and I told myself it'd be easier to support users that way.

Sounds excellent. For instance Python is packaged in the same way.
(/Library/Frameworks/Python.framework and symlinks from /usr/local)

For a hybrid environment like Mac OS X it makes sense to use both...
Then the user can either use the Unix way or set it up like Windows.

> Now, the only missing piece for an easy manual replacement of DMD is a zip archive where the executable bit is set.

Hard to believe that bit is still missing, after all these years.

--anders
August 05, 2010
On 2010-08-04 12:34, Walter Bright wrote:
> Don wrote:
>> Walter Bright wrote:
>>> Jacob Carlborg wrote:
>>>> Am not sure about 1441 and I don't think 2529 is just an
>>>> implementation issue.
>>>
>>> 2529 is an implementation issue (and I don't agree with Don, I think
>>> his suggestion breaks encapsulation).
>>
>> Maybe it does. I think the bug should be closed as invalid, because
>> the initial suggestion in the bug report is completely wrong: it would
>> drive you to put low-level stuff in the root, and derived stuff in the
>> leaves.
>> Implementing that suggestion would encourage poor design.
>
> Please add this as a comment to the entry.
>
>> I believe D's current approach is what Java does?
>
> I'm not sure what Java does.

I'm pretty sure that D's and Java's approach is the same.

-- 
/Jacob Carlborg
August 05, 2010
On 2010-08-05 01:21, Michel Fortin wrote:
> On 2010-08-04 15:31:32 -0400, Walter Bright <newshound2@digitalmars.com>
> said:
>
>> Michel Fortin wrote:
>>> As a side note, my D plugin for Xcode expects DMD to be available at
>>> /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in
>>> /usr/local/lib. It won't work if the files can't be found there,
>>> although I might change that if an official distribution of DMD
>>> installs itself elsewhere.
>>
>> To me, the biggest problem is deciding where the files should go.
>> There doesn't seem to be any consensus or culture in OS X about this.
>
> I agree. It took me quite a while to decide to do things as I did. The
> goals were:
>
> 1. It should be easy to manually replace DMD from a new package from
> Digital Mars.
> 2. It should work on the command line with no user intervention (no need
> to add something to $PATH in the bash profile for instance).
> 3. It should not mess with the system directories.
>
> Except when it come from third party package managers (fink, MacPorts),
> most Unix software not coming from Apple installs in /usr/local on Mac
> OS X (for instance I have: MySQL, Git, Mercurial, Doxygen, 7za and a
> couple others there). So it makes a lot of sense to install it there.
>
> To make manual replacement easy, I wanted to preserve the dmd and dmd2
> directories from the zip archive intact, so it's easy to swap them for
> another one. Initially, I decided to use /usr/local/dmd and
> /usr/local/dmd2, and add with symlinks in /usr/local/{bin,lib,man} to
> make everything work from the command line without changing $PATH.
>
> Symlinks didn't work quite well: dmd takes the value of args[0] to know
> which directory to search for dmd.conf. I guess I could have installed a
> dmd.conf in /etc/ to override that, but then how do you install dmd1 and
> dmd2 side by side? So what I did is replace the symlinks with a sort of
> trampoline program that adjusts the value of the args[0] for the path of
> the DMD just before calling exec(), allowing a different dmd.conf to be
> used for each one.
>
> And using /usr/local/{dmd,dmd2} wasn't entirely satisfactory either. Mac
> OS X hides the /usr folder when you browse using the Finder. So
> replacing /usr/local/{dmd,dmd2} manually with a newer one isn't as
> straightforward as it should be. I settled on using
> /Library/Compilers/{dmd,dmd2}. This isn't entirely satisfactory either
> since it doesn't follow UNIX ways, but it's not too far of how Mac OS X
> is packaged and I told myself it'd be easier to support users that way.
>
> Now, the only missing piece for an easy manual replacement of DMD is a
> zip archive where the executable bit is set.

I would vote for something like this, making it easy to have dmd and dm2 installed side by side and to easily manually update the compiler to a newer version. I would name the trampoline programs dmd1 and dmd2 and then make a symlink named dmd pointing to dmd1 or dmd2.

-- 
/Jacob Carlborg
August 05, 2010
On 2010-08-05 07:14:19 -0400, Jacob Carlborg <doob@me.com> said:

> I would vote for something like this, making it easy to have dmd and dm2 installed side by side and to easily manually update the compiler to a newer version. I would name the trampoline programs dmd1 and dmd2 and then make a symlink named dmd pointing to dmd1 or dmd2.

The D for Xcode installer does all this and also installs a small command to easily change which version the dmd symlink points to:

	$ sudo setdmd 1
	$ dmd -v
	Digital Mars D Compiler v1.062
	...

	$ sudo setdmd 2
	$ dmd -v
	Digital Mars D Compiler v2.047
	...


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/