August 03, 2009
Michel Fortin wrote:
>> I think I like /usr/local best.
> 
> I like /usr/local best too.

The objection (if any) was mostly about "/usr/local/dmd/osx/bin"
vs /usr/local/bin, but using /usr/local/{dmd,dmd2} should be OK.

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

Such as the language extensions in /Library/Perl and /Library/Python
already mentioned, elsewhere in /usr/lib/perl5 and /usr/lib/python2.X

>> What about /Applications?
> 
> I thought that was for applications. DMD isn't an appliction, it's a command-line tool.

And even if it was, it would probably go in /Developer anyway ?
Like /Developer/Applications/CodeBlocks.app does, for instance.

--anders
August 07, 2009
On 8/3/09 14:32, Anders F Björklund wrote:
> Michel Fortin wrote:
>>> I think I like /usr/local best.
>>
>> I like /usr/local best too.
>
> The objection (if any) was mostly about "/usr/local/dmd/osx/bin"
> vs /usr/local/bin, but using /usr/local/{dmd,dmd2} should be OK.

I was thinking about using /usr/local/{dmd,dmd2} and then create symlinks to /usr/local/bin. But that will create problems with the dmd.conf because it also needs a symlink in /usr/local/bin and then the conf file for dmd and dmd1 will conflict.

>>> Library directory is a special directory used to store
>>> application-specific and system-specific resources".
>>
>> Indeed.
>
> Such as the language extensions in /Library/Perl and /Library/Python
> already mentioned, elsewhere in /usr/lib/perl5 and /usr/lib/python2.X
>
>>> What about /Applications?
>>
>> I thought that was for applications. DMD isn't an appliction, it's a
>> command-line tool.
>
> And even if it was, it would probably go in /Developer anyway ?
> Like /Developer/Applications/CodeBlocks.app does, for instance.
>
> --anders

August 07, 2009
On 2009-08-07 08:05:04 -0400, Jacob Carlborg <doob@me.com> said:

> On 8/3/09 14:32, Anders F Björklund wrote:
>> Michel Fortin wrote:
>>>> I think I like /usr/local best.
>>> 
>>> I like /usr/local best too.
>> 
>> The objection (if any) was mostly about "/usr/local/dmd/osx/bin"
>> vs /usr/local/bin, but using /usr/local/{dmd,dmd2} should be OK.
> 
> I was thinking about using /usr/local/{dmd,dmd2} and then create symlinks to /usr/local/bin. But that will create problems with the dmd.conf because it also needs a symlink in /usr/local/bin and then the conf file for dmd and dmd1 will conflict.

The solution is to create a "symlink program" and drop it in /usr/local/bin. I know it works; I wrote one to do just that:

	#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);
	}

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

August 07, 2009
On 2009-08-07 08:05:04 -0400, Jacob Carlborg <doob@me.com> said:

> I was thinking about using /usr/local/{dmd,dmd2} and then create symlinks to /usr/local/bin. But that will create problems with the dmd.conf because it also needs a symlink in /usr/local/bin and then the conf file for dmd and dmd1 will conflict.

Also, could you make symlinks for "dmd" (prefered version), "dmd1" and "dmd2" in /usr/local/bin ? This should allow projects to use explicitely dmd1 or dmd2 when needed, while the user could rebind dmd to one or the other depending on his needs.

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

August 07, 2009
Michel Fortin wrote:
>>> The objection (if any) was mostly about "/usr/local/dmd/osx/bin"
>>> vs /usr/local/bin, but using /usr/local/{dmd,dmd2} should be OK.
>>
>> I was thinking about using /usr/local/{dmd,dmd2} and then create symlinks to /usr/local/bin. But that will create problems with the dmd.conf because it also needs a symlink in /usr/local/bin and then the conf file for dmd and dmd1 will conflict.
> 
> The solution is to create a "symlink program" and drop it in /usr/local/bin. I know it works; I wrote one to do just that:
> 
>     #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);
>     }

I did that for my linux package, but used shell instead.
Then the dmd.conf was a link back to the real config file,
to /etc/dmd.conf for dmd and to /etc/dmd2.conf for dmd2...

/usr/bin/dmd2 -> /usr/libexec/dmd2/dmd
/usr/libexec/dmd2/dmd.conf -> /etc/dmd2.conf
Then the conf files didn't conflict anymore.

--anders
August 12, 2009
On 8/7/09 17:32, Anders F Björklund wrote:
> Michel Fortin wrote:
>>>> The objection (if any) was mostly about "/usr/local/dmd/osx/bin"
>>>> vs /usr/local/bin, but using /usr/local/{dmd,dmd2} should be OK.
>>>
>>> I was thinking about using /usr/local/{dmd,dmd2} and then create
>>> symlinks to /usr/local/bin. But that will create problems with the
>>> dmd.conf because it also needs a symlink in /usr/local/bin and then
>>> the conf file for dmd and dmd1 will conflict.
>>
>> The solution is to create a "symlink program" and drop it in
>> /usr/local/bin. I know it works; I wrote one to do just that:
>>
>> #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);
>> }
>
> I did that for my linux package, but used shell instead.
> Then the dmd.conf was a link back to the real config file,
> to /etc/dmd.conf for dmd and to /etc/dmd2.conf for dmd2...
>
> /usr/bin/dmd2 -> /usr/libexec/dmd2/dmd
> /usr/libexec/dmd2/dmd.conf -> /etc/dmd2.conf
> Then the conf files didn't conflict anymore.
>
> --anders

If I understand you correctly you have a symlink "/usr/bin/dmd2" pointing to "/usr/libexec/dmd2/dmd" and then a symlink "/usr/libexec/dmd2/dmd.conf" pointing to "/etc/dmd2.conf".

I can't see how that would work, correct me if I'm wrong: dmd will only search for a conf file named dmd.conf in the same path as the dmd executable, in /etc or in the user home directory.

dmd will not find the file in /etc because it's named "dmd2.conf". The file "usr/libexec/dmd2/dmd.conf" will not work because the dmd.conf will needs to be in the same directory as the symlink and not the actual executable, this was the first I tried.

/Jacob Carlborg
August 12, 2009
Jacob Carlborg wrote:

>>> The solution is to create a "symlink program" and drop it in
>>> /usr/local/bin. I know it works; I wrote one to do just that:
>>>
>>> #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);
>>> }
>>
>> I did that for my linux package, but used shell instead.
>> Then the dmd.conf was a link back to the real config file,
>> to /etc/dmd.conf for dmd and to /etc/dmd2.conf for dmd2...
>>
>> /usr/bin/dmd2 -> /usr/libexec/dmd2/dmd
>> /usr/libexec/dmd2/dmd.conf -> /etc/dmd2.conf
>> Then the conf files didn't conflict anymore.
>>
>> --anders
> 
> If I understand you correctly you have a symlink "/usr/bin/dmd2" pointing to "/usr/libexec/dmd2/dmd" and then a symlink "/usr/libexec/dmd2/dmd.conf" pointing to "/etc/dmd2.conf".
> 
> I can't see how that would work, correct me if I'm wrong: dmd will only search for a conf file named dmd.conf in the same path as the dmd executable, in /etc or in the user home directory.
> 
> dmd will not find the file in /etc because it's named "dmd2.conf". The file "usr/libexec/dmd2/dmd.conf" will not work because the dmd.conf will needs to be in the same directory as the symlink and not the actual executable, this was the first I tried.

Right, /usr/libexec/dmd2/dmd is the actual program.
And /usr/bin/dmd2 was a wrapper that exec'd it...

#!/bin/sh
exec /usr/libexec/dmd2/dmd "$*"

Guess one could use the same workaround for moving
dmd over to "dmd1", and make dmd into a symlink ?

dmd -> dmd1 # depending on
dmd -> dmd2 # your preference

--anders

http://www.digitalmars.com/d/archives/digitalmars/D/announce/DMD_1.029_and_2.013_releases_11949.html#N11988
August 13, 2009
On 2009-08-12 19:37:13 -0400, Anders F Björklund <afb@algonet.se> said:

> Guess one could use the same workaround for moving
> dmd over to "dmd1", and make dmd into a symlink ?
> 
> dmd -> dmd1 # depending on
> dmd -> dmd2 # your preference

That's something I'd really like to see.

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

August 13, 2009
Michel Fortin wrote:

>> Guess one could use the same workaround for moving
>> dmd over to "dmd1", and make dmd into a symlink ?
>>
>> dmd -> dmd1 # depending on
>> dmd -> dmd2 # your preference
> 
> That's something I'd really like to see.

It's done the same with GCC, too:

/usr/bin/gcc -> gcc-4.0
/usr/bin/gcc-3.3
/usr/bin/gcc-4.0
/usr/bin/gcc2
/usr/bin/gcc3

Was even a gcc_select(8) program.

--anders

PS.
But now it's all gcc-4.2 instead, and
with or without LLVM is the question.
Of course neither of the Apple compilers
works very well with GDC any longer...
19 20 21 22 23 24 25 26 27 28 29
Next ›   Last »