July 31, 2009
On 7/23/09 12:32 PM, Michel Fortin wrote:
> On 2009-07-23 05:37:24 -0400, Jacob Carlborg <doob@me.com> said:
>
>> Yes: http://www.dsource.org/projects/dmd-installer
>> I'm still waiting for Walter to add the osx installer to the dmd
>> download page.
>
> Speaking of that OS X DMD installer, are you sure installing it at
> /usr/share/dmd/ is a good idea? Normally /usr/share is reserved for
> architecture-independent data[1], not executable files. What about
> /usr/local/dmd with symlinks in /usr/local/bin for executables
> /usr/local/lib for phobos and druntime and /usr/local/man for man pages.
> Or perhaps install /Library/D/{dmd,dmd2} so the files are more user
> accessible and easy to change if you got the zip archive (/usr is a
> hidden dir on Mac OS X).
>
> If I'm not mistaken, both your D1 and D2 installer install at the same
> location and they will overwrite each other. I'd much prefer if D2 and
> D1 could coexist without having to go with a special installer or custom
> installation instructions. Otherwise it'll be hard for me to offer the
> choice between D1 and D2 in Xcode (and I certainly do want that choice
> to be available).
>
> Thoughts?
>
>
> [1]: http://www.pathname.com/fhs/2.2/fhs-4.11.html
>

Sorry I haven't replied sooner I've been on vacation.

I looked at a gdc installer and looked where it placed the compiler and did the same. I don't know where it's best to place the compiler.

/Jacob Carlborg
August 01, 2009
Walter Bright wrote:

> I don't know what build tools you're using, but consider make:
> 
> ------ win32.mak ---------
> 
> DMD=\dmd\windows\bin\dmd
> 
> target : foo.obj
> 
> foo.obj : foo.d
>     $(DMD) -c foo
> --------------------------

And for GNU make, it uses the variables $(DC) and $(DMD)
where DC is the D compiler (like CC) and DMD the wrapper.

The annoying part is changing the DFLAGS for the compiler,
and/or translating any needed linker flags for the wrapper...

ifeq ("$(COMPILER)","DMD")
DC ?= dmd
DMD ?= dmd
DFLAGS = -O -g
version=-version
output=-of$@
endif
ifeq ("$(COMPILER)","LDC")
DC ?= ldc
DMD ?= ldmd
DFLAGS = -O
version=-d-version
output=-of=$@
endif
ifeq ("$(COMPILER)","GDC")
DC ?= gdc
DMD ?= gdmd
DFLAGS = -O2 -g
version=-fversion
output=-o $@
endif

%.o:%.d
	$(DC) $(DFLAGS) -c $(output) $<

--anders
August 01, 2009
Jacob Carlborg wrote:

>> Speaking of that OS X DMD installer, are you sure installing it at
>> /usr/share/dmd/ is a good idea? [...]
> I looked at a gdc installer and looked where it placed the compiler and did the same. I don't know where it's best to place the compiler.

You can use /opt/dmd and /opt/dmd2, if you don't
want to use the regular file hierarchy in hier(7)

DMD = /opt/dmd2/osx/bin/dmd

Or you can use e.g. /usr/local/bin and rename to
dmd2 and dmd2.conf (which takes some trickery...)

DMD = dmd2

--anders
August 01, 2009
On 2009-08-01 04:41:38 -0400, Anders F Björklund <afb@algonet.se> said:

> Jacob Carlborg wrote:
> 
>>> Speaking of that OS X DMD installer, are you sure installing it at
>>> /usr/share/dmd/ is a good idea? [...]
>> I looked at a gdc installer and looked where it placed the compiler and did the same. I don't know where it's best to place the compiler.
> 
> You can use /opt/dmd and /opt/dmd2, if you don't
> want to use the regular file hierarchy in hier(7)
> 
> DMD = /opt/dmd2/osx/bin/dmd
> 
> Or you can use e.g. /usr/local/bin and rename to
> dmd2 and dmd2.conf (which takes some trickery...)
> 
> DMD = dmd2

In hier(7), it says that "/usr/local" is for "executables, libraries, etc. not included by the basic operating system", so I guess DMD fits this quite well.

I'm preparing an installer for D for Xcode and made it install DMD at /usr/local/dmd and /usr/local/dmd2, with symlinks at /usr/local/bin/dmd (system-prefered version) /usr/local/bin/dmd1 (1.x) and /usr/local/bin/dmd2 (2.x). This makes it easy to choose the version you want within Xcode.

For some reasons, the symlinks works fine with Xcode. But they aren't working from the command line (dmd complains that it can't find object.o). I've made a small C program to replace the symlink:

	#include <unistd.h>

	int main(unsigned int argc, char **argv) {
		argv[0] = "/usr/local/dmd/osx/bin/dmd";
		execv("/usr/local/dmd/osx/bin/dmd", argv);
	}

No more problem from the command line.

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

August 01, 2009
Michel Fortin wrote:

>> You can use /opt/dmd and /opt/dmd2, if you don't
>> want to use the regular file hierarchy in hier(7)

> In hier(7), it says that "/usr/local" is for "executables, libraries, etc. not included by the basic operating system", so I guess DMD fits this quite well.

I normally* use the regular /usr/local/bin and
/usr/local/lib and so on, when using /usr/local
and otherwise /opt for various vendor layouts...
But I suppose /usr/local/dmd "works" just fine.

Renaming dmd to dmd1 probably makes sense, once
dmd2 is released, and switching with the symlink.
Was using something similar to switch between the
Phobos and Tango libraries in earlier versions.

--anders

* GDC was using /usr/bin, since it was sharing
  some files with /usr/bin/gcc already anyway.
August 02, 2009
Sat, 1 Aug 2009 07:55:08 -0400, Michel Fortin wrote:

> On 2009-08-01 04:41:38 -0400, Anders F Björklund <afb@algonet.se> said:
> 
>> Jacob Carlborg wrote:
>> 
>>>> Speaking of that OS X DMD installer, are you sure installing it at /usr/share/dmd/ is a good idea? [...]
>>> I looked at a gdc installer and looked where it placed the compiler and did the same. I don't know where it's best to place the compiler.
>> 
>> You can use /opt/dmd and /opt/dmd2, if you don't
>> want to use the regular file hierarchy in hier(7)
>> 
>> DMD = /opt/dmd2/osx/bin/dmd
>> 
>> Or you can use e.g. /usr/local/bin and rename to
>> dmd2 and dmd2.conf (which takes some trickery...)
>> 
>> DMD = dmd2
> 
> In hier(7), it says that "/usr/local" is for "executables, libraries, etc. not included by the basic operating system", so I guess DMD fits this quite well.
> 
> I'm preparing an installer for D for Xcode and made it install DMD at /usr/local/dmd and /usr/local/dmd2, with symlinks at /usr/local/bin/dmd (system-prefered version) /usr/local/bin/dmd1 (1.x) and /usr/local/bin/dmd2 (2.x). This makes it easy to choose the version you want within Xcode.
> 
> For some reasons, the symlinks works fine with Xcode. But they aren't working from the command line (dmd complains that it can't find object.o). I've made a small C program to replace the symlink:
> 
> 	#include <unistd.h>
> 
> 	int main(unsigned int argc, char **argv) {
> 		argv[0] = "/usr/local/dmd/osx/bin/dmd";
> 		execv("/usr/local/dmd/osx/bin/dmd", argv);
> 	}
> 
> No more problem from the command line.

Here's a nice document about directory layout in UNIX-like OSes:

http://www.pathname.com/fhs/pub/fhs-2.3.html

I think MacOS should follow this layout at least in part.  In particular /usr/local/ is used for locally installed packages which otherwise respect the standard directory structure found in / or /usr/.  That is, binaries go into /usr/local/bin/, libraries in /usr/local/lib/ etc.  If a package wants to keep its own structure it's supposted to go into /opt/, like /opt/dmd2/whatever.
August 02, 2009
On 2009-08-01 20:15:41 -0400, Sergey Gromov <snake.scaly@gmail.com> said:

> Here's a nice document about directory layout in UNIX-like OSes:
> 
> http://www.pathname.com/fhs/pub/fhs-2.3.html
> 
> I think MacOS should follow this layout at least in part.  In particular
> /usr/local/ is used for locally installed packages which otherwise
> respect the standard directory structure found in / or /usr/.  That is,
> binaries go into /usr/local/bin/, libraries in /usr/local/lib/ etc.  If
> a package wants to keep its own structure it's supposted to go into
> /opt/, like /opt/dmd2/whatever.

Well, given that this is Mac OS X we could also put this in /Library/D/dmd and /Library/D/dmd2, two directories which aren't hidden by the file browser. Then put symlinks in /usr/local/bin and /usr/local/lib pointing there. Users will then be able to upgrade without an installer by simply replacing the folder at /Library/D/dmd & dmd2 with a newly downloaded one.

I think that's better than /opt, as /opt isn't present by default on Mac OS X, isn't hidden by the Finder when present (contrary to all other "UNIX" directories at the root) and thus would look a little out of place on the hard drive. And there's already /Library/Python, /Library/PHP and /Library/Ruby in that /Library directory to set a precedent.

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

August 02, 2009
Michel Fortin wrote:

> Well, given that this is Mac OS X we could also put this in /Library/D/dmd and /Library/D/dmd2, two directories which aren't hidden by the file browser. Then put symlinks in /usr/local/bin and /usr/local/lib pointing there. Users will then be able to upgrade without an installer by simply replacing the folder at /Library/D/dmd & dmd2 with a newly downloaded one.

That's how the zip files work, yes ? Possibly PATH instead of symlinks.

Main difference between /Library/D and ~ is that it requires "admin"
privileges while anyone can install into ~/dmd (even if not an admin)

The /usr installer for GDC requires root, so it auths as admin first.

Then again that gdc needed to be installed into system gcc locations,
so it wasn't really relocatable like the upstream tarball from dgcc.

> I think that's better than /opt, as /opt isn't present by default on Mac OS X, isn't hidden by the Finder when present (contrary to all other "UNIX" directories at the root) and thus would look a little out of place on the hard drive. And there's already /Library/Python, /Library/PHP and /Library/Ruby in that /Library directory to set a precedent.

I think /Library/{Python,Perl,Ruby} are mostly used for user modules ?

The actual interpreters are normally installed under /usr or /usr/local
Possibly symlinked, in case of a framework installation (like Python's)

You could also use the /Developer hierarchy for installing compilers.

But I would use a "commandline" directory for a commandline tool, rather
than having it Finder-browsable. It might make sense for docs and such.

--anders
August 03, 2009
On 8/2/09 03:40, Michel Fortin wrote:
> On 2009-08-01 20:15:41 -0400, Sergey Gromov <snake.scaly@gmail.com> said:
>
>> Here's a nice document about directory layout in UNIX-like OSes:
>>
>> http://www.pathname.com/fhs/pub/fhs-2.3.html
>>
>> I think MacOS should follow this layout at least in part. In particular
>> /usr/local/ is used for locally installed packages which otherwise
>> respect the standard directory structure found in / or /usr/. That is,
>> binaries go into /usr/local/bin/, libraries in /usr/local/lib/ etc. If
>> a package wants to keep its own structure it's supposted to go into
>> /opt/, like /opt/dmd2/whatever.
>
> Well, given that this is Mac OS X we could also put this in
> /Library/D/dmd and /Library/D/dmd2, two directories which aren't hidden
> by the file browser. Then put symlinks in /usr/local/bin and
> /usr/local/lib pointing there. Users will then be able to upgrade
> without an installer by simply replacing the folder at /Library/D/dmd &
> dmd2 with a newly downloaded one.
>
> I think that's better than /opt, as /opt isn't present by default on Mac
> OS X, isn't hidden by the Finder when present (contrary to all other
> "UNIX" directories at the root) and thus would look a little out of
> place on the hard drive. And there's already /Library/Python,
> /Library/PHP and /Library/Ruby in that /Library directory to set a
> precedent.
>

I think I like /usr/local best. /Library is used for resources: http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI

"The Library directory is a special directory used to store application-specific and system-specific resources".

What about /Applications?
August 03, 2009
On 2009-08-03 06:59:14 -0400, Jacob Carlborg <doob@me.com> said:

> I think I like /usr/local best.

I like /usr/local best too.

> /Library is used for resources: http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI

"The 
> 
> Library directory is a special directory used to store application-specific and system-specific resources".

Indeed.

> What about /Applications?

I thought that was for applications. DMD isn't an appliction, it's a command-line tool.

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