www.digitalmars.com         C & C++   DMDScript  

D.gnu - Renaming libphobos for GDC and dmd driver script.

reply Dave <Dave_member pathlink.com> writes:
As a user of both DMD and GDC, I would like to request that some thought be put
into renaming the GDC driver script (from dmd) and GDC libphobos to avoid
conflicts.

I know, there are several technical 'hacks' around this issue but the problem is
that the default installations of both DMD and GDC create the conflicts, and the
surest and cleanest way around that (especially for newbies) is to rename the
as-installed script and library for GDC.

I've hesitated for months to bring this up because I feared it could lead to
some sort of a political battle, which I assure everyone is NOT my intent.
However, there is a technical hurdle to overcome here and the simple fact of the
matter is that DMD was 'here first' if you will.

As an aside, and given the general (if unwritten) rule about knowingly 'stepping
on' other software installations, I've got to ask myself why this conflict was
created in the first place. I apologize if this is a topic already covered. If
so please point me to the archives..

- Dave
May 05 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Dave wrote:


 As a user of both DMD and GDC, I would like to request that some thought be put
 into renaming the GDC driver script (from dmd) and GDC libphobos to avoid
 conflicts.


The script is actually called "dmd-script", and only renamed to dmd as a 
convenience. And since "libphobos.a" is implicit and static, it could be 
renamed... (e.g. I've done a "libphobos-contracts.a", without -release)
Perhaps a name like "libphobos-gcc.a", or move into the gcc-lib dir ?
(i.e. next to libgcc.a and such, then it could remain as "libphobos.a")

The dmd command could be added as a *symlink* to "dmd-script", instead ?
(and only if the "dmd" program didn't already exist, as a real program)

- bin/dmd -> dmd-script
- bin/dmd-script
- bin/gdc

- lib/libphobos.a -> gcc/i686-redhat-linux/3.4.3/libphobos.a
- lib/gcc/i686-redhat-linux/3.4.3/libphobos.a
- lib/libphobos.spec

- man/man1/dmd.1 -> dmd-script.1
- man/man1/dmd-script.1
- man/man1/gdc.1

Installing the "real" DMD later, would then wipe the links with files ?
(and if DMD was already present, then the symlinks wouldn't be created)

So I don't think it's "a technical problem", just a minor political one.


In my pre-made packages, I've put DMD's Phobos files in /usr/lib/phobos
and GDC's Phobos files under /usr/include/d - so no conflicts there...

There is also a similar conflict with "DFLAGS" environment variable,
which is for DMD only. GDC must use something like "DCFLAGS" instead.



 I know, there are several technical 'hacks' around this issue but the problem
is
 that the default installations of both DMD and GDC create the conflicts, and
the
 surest and cleanest way around that (especially for newbies) is to rename the
 as-installed script and library for GDC.


I have another suggestion, and that is that GDC is soon "clean" enough
to move into the standard install locations... (i.e. /usr, usually)

One reason for keeping in /opt is the lack of a uninstaller on Mac OS X,
but that can be fixed by providing a "Uninstall" script ? (like on Win)

It used to be that you had to install GDC in a different location on
for instance Mac OS X, since it wasn't compatible with system GCC/G++.

But it is now, so it should be able to move from /opt/gdc to %{_prefix}.
If "dmd-script" and "libphobos.a" were renamed, less conflicts with DMD.

The gdcmac installation (for Panther / GCC 3.3) currently consists of:
- bin/dmd
- bin/gdc
- include/d (directory only)
- include/d/3.3.5/*
- lib/gcc-lib (directory only)
- lib/gcc-lib/powerpc-apple-darwin7.9.0/3.3.5/*
- lib/libphobos.a
- lib/libphobos.spec
- share/man/man1/dmd.1
- share/man/man1/gdc.1

"/usr" would get rid of the "PATH setup" step, which would be nice...
(but no conflicts on the Mac/PowerPC platform, since DMD is X86 only)

This could all be "fixed" for GDC 0.12

--anders

PS.
"libphobos.spec" isn't needed on Mac, but holds "-lm -lpthread" on Linux
(both of libm and libpthread are contained in libSystem, under Mac OS X)
May 06 2005
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anders F Björklund schrieb am Fri, 06 May 2005 09:42:08 +0200:

 PS.
 "libphobos.spec" isn't needed on Mac, but holds "-lm -lpthread" on Linux
 (both of libm and libpthread are contained in libSystem, under Mac OS X)


Linux:
Providing a specs file at an alternative location works as long as there
is at least an empty file at the default location, mhhh...

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCe2Fc3w+/yD4P9tIRApuMAJ9MWRR2o/72QoiR4gak8Gc4anpGcwCgyx4b
XQ+r/q4zPzytBXSnPYIU0bA=
=IWTm
-----END PGP SIGNATURE-----
May 06 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Thomas Kuehne wrote:


"libphobos.spec" isn't needed on Mac, but holds "-lm -lpthread" on Linux
(both of libm and libpthread are contained in libSystem, under Mac OS X)


 
 Linux:
 Providing a specs file at an alternative location works as long as there
 is at least an empty file at the default location, mhhh...


It needs an "empty" file on Mac too, I meant it doesn't add anything:






%rename lib liborig
*lib: %(liborig)

Currently (GDC 0.11) it adds -lm, but that is redundant on Mac
("libm.dylib" is just a symlink to libSystem.dylib, anyway...)

--anders
May 06 2005
prev sibling parent reply David Friedman <d3rdclsmail_a t_earthlink_d.t_net> writes:
Anders F Björklund wrote:

 Dave wrote:
 

 As a user of both DMD and GDC, I would like to request that some 
 thought be put
 into renaming the GDC driver script (from dmd) and GDC libphobos to avoid
 conflicts.


 
 
 The script is actually called "dmd-script", and only renamed to dmd as a 
 convenience. And since "libphobos.a" is implicit and static, it could be 


Actually, it's named "dmd-script" because the directory already has a 
subdirectory named "dmd" :-)


 renamed... (e.g. I've done a "libphobos-contracts.a", without -release)
 Perhaps a name like "libphobos-gcc.a", or move into the gcc-lib dir ?
 (i.e. next to libgcc.a and such, then it could remain as "libphobos.a")
 
 The dmd command could be added as a *symlink* to "dmd-script", instead ?
 (and only if the "dmd" program didn't already exist, as a real program)
 
 - bin/dmd -> dmd-script
 - bin/dmd-script
 - bin/gdc
 
 - lib/libphobos.a -> gcc/i686-redhat-linux/3.4.3/libphobos.a
 - lib/gcc/i686-redhat-linux/3.4.3/libphobos.a
 - lib/libphobos.spec
 
 - man/man1/dmd.1 -> dmd-script.1
 - man/man1/dmd-script.1
 - man/man1/gdc.1
 
 Installing the "real" DMD later, would then wipe the links with files ?
 (and if DMD was already present, then the symlinks wouldn't be created)
 
 So I don't think it's "a technical problem", just a minor political one.
 


I could put this logic in the Makefile, but it wouldn't help for 
building a package.  I think the package would need an install script 
that did the same thing.

Here's what I could do:

1. Always install dmd-script as 'gdmd'
2. Always link 'dmd' to 'gdmd'
3. It would be up to the package builder how to handle 'dmd'.  The link
    could be removed from the file list and be created as you described.

David


 
 In my pre-made packages, I've put DMD's Phobos files in /usr/lib/phobos
 and GDC's Phobos files under /usr/include/d - so no conflicts there...
 
 There is also a similar conflict with "DFLAGS" environment variable,
 which is for DMD only. GDC must use something like "DCFLAGS" instead.
 
 

 I know, there are several technical 'hacks' around this issue but the 
 problem is
 that the default installations of both DMD and GDC create the 
 conflicts, and the
 surest and cleanest way around that (especially for newbies) is to 
 rename the
 as-installed script and library for GDC.


 
 
 I have another suggestion, and that is that GDC is soon "clean" enough
 to move into the standard install locations... (i.e. /usr, usually)
 
 One reason for keeping in /opt is the lack of a uninstaller on Mac OS X,
 but that can be fixed by providing a "Uninstall" script ? (like on Win)
 
 It used to be that you had to install GDC in a different location on
 for instance Mac OS X, since it wasn't compatible with system GCC/G++.
 
 But it is now, so it should be able to move from /opt/gdc to %{_prefix}.
 If "dmd-script" and "libphobos.a" were renamed, less conflicts with DMD.
 
 The gdcmac installation (for Panther / GCC 3.3) currently consists of:
 - bin/dmd
 - bin/gdc
 - include/d (directory only)
 - include/d/3.3.5/*
 - lib/gcc-lib (directory only)
 - lib/gcc-lib/powerpc-apple-darwin7.9.0/3.3.5/*
 - lib/libphobos.a
 - lib/libphobos.spec
 - share/man/man1/dmd.1
 - share/man/man1/gdc.1
 
 "/usr" would get rid of the "PATH setup" step, which would be nice...
 (but no conflicts on the Mac/PowerPC platform, since DMD is X86 only)
 
 This could all be "fixed" for GDC 0.12
 
 --anders
 
 PS.
 "libphobos.spec" isn't needed on Mac, but holds "-lm -lpthread" on Linux
 (both of libm and libpthread are contained in libSystem, under Mac OS X)
May 06 2005
parent reply Dave <Dave_member pathlink.com> writes:
In article <d5gdso$161b$1 digitaldaemon.com>, David Friedman says...

Anders F Björklund wrote:

 Dave wrote:
 

 As a user of both DMD and GDC, I would like to request that some 
 thought be put
 into renaming the GDC driver script (from dmd) and GDC libphobos to avoid
 conflicts.


 
 
 The script is actually called "dmd-script", and only renamed to dmd as a 
 convenience. And since "libphobos.a" is implicit and static, it could be 


Actually, it's named "dmd-script" because the directory already has a 
subdirectory named "dmd" :-)


 renamed... (e.g. I've done a "libphobos-contracts.a", without -release)
 Perhaps a name like "libphobos-gcc.a", or move into the gcc-lib dir ?
 (i.e. next to libgcc.a and such, then it could remain as "libphobos.a")
 
 The dmd command could be added as a *symlink* to "dmd-script", instead ?
 (and only if the "dmd" program didn't already exist, as a real program)
 
 - bin/dmd -> dmd-script
 - bin/dmd-script
 - bin/gdc
 
 - lib/libphobos.a -> gcc/i686-redhat-linux/3.4.3/libphobos.a
 - lib/gcc/i686-redhat-linux/3.4.3/libphobos.a
 - lib/libphobos.spec
 
 - man/man1/dmd.1 -> dmd-script.1
 - man/man1/dmd-script.1
 - man/man1/gdc.1
 
 Installing the "real" DMD later, would then wipe the links with files ?
 (and if DMD was already present, then the symlinks wouldn't be created)
 
 So I don't think it's "a technical problem", just a minor political one.
 


I could put this logic in the Makefile, but it wouldn't help for 
building a package.  I think the package would need an install script 
that did the same thing.

Here's what I could do:

1. Always install dmd-script as 'gdmd'
2. Always link 'dmd' to 'gdmd'
3. It would be up to the package builder how to handle 'dmd'.  The link
    could be removed from the file list and be created as you described.

David


Cool and thank you for considering this so quickly!

IMHO, the dmd symlink should not be done at all (in the GDC distro. or by any
package builders) just because of the potential for newbie confusion and/or the
need to modify PATH, or leave one out of PATH and use an absolute path for the
other, etc..

I would like to be able to just change one line in the Makefiles from 'DMD' to
'GDMD' (for example) to switch compilers. Same on the command line for testing
purposes.

That way it will never be confusing to new users, and dual-users won't have to
mess around with PATH, etc.

Don't get me wrong, the gdc wrapper script is definately a value-add and a great
idea, and renaming the library as you mentioned in the earlier post sounds
great!

Thanks,

- Dave
May 06 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Dave wrote:


Here's what I could do:

1. Always install dmd-script as 'gdmd'
2. Always link 'dmd' to 'gdmd'
3. It would be up to the package builder how to handle 'dmd'.  The link
   could be removed from the file list and be created as you described.


 
 Cool and thank you for considering this so quickly!
 
 IMHO, the dmd symlink should not be done at all (in the GDC distro. or by any
 package builders) just because of the potential for newbie confusion and/or the
 need to modify PATH, or leave one out of PATH and use an absolute path for the
 other, etc..


Symlinks doesn't work all the time, either. Some inferior file systems 
(Win) and inferior package systems (Mac) needs to have copies instead...

It would probably be easier to call it "gdmd", as suggested by David.
Easy enough to add dmd as a local shell alias, if wanted by the user ?


 I would like to be able to just change one line in the Makefiles from 'DMD' to
 'GDMD' (for example) to switch compilers. Same on the command line for testing
 purposes.


Hmm, you mean that "DMD" with a lower case - I guess ?

Like this Makefile snippet:

CC=dmc
CFLAGS=-o
DMD=dmd
DFLAGS=-O -release

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


There you would need to do something like "make DMD=gdmd",
to use the wrapper for GDC - instead of the DMD compiler.

An alternative would be to use "DC", instead of "DMD":

CC=gcc
CFLAGS=-O2
CXX=g++
CXXFLAGS=-O2
DC=gdc
DCFLAGS=-O2 -frelease

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

Note that the flags are different, between the two.
(I suggested using different make variables, too...)


 That way it will never be confusing to new users, and dual-users won't have to
 mess around with PATH, etc.


It would also simplify installation into alternate paths,
like used by DarwinPorts and Fink and other such systems...

Since in those systems, there is only one %{_bin} directory.
Gentoo would be another system, that would benefit from this.

--anders
May 07 2005
parent "Dave" <Dave_member pathlink.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d5hsk6$27ol$1 digitaldaemon.com...

 Dave wrote:


Here's what I could do:

1. Always install dmd-script as 'gdmd'
2. Always link 'dmd' to 'gdmd'
3. It would be up to the package builder how to handle 'dmd'.  The link
   could be removed from the file list and be created as you described.


 Cool and thank you for considering this so quickly!

 IMHO, the dmd symlink should not be done at all (in the GDC distro. or by 
 any
 package builders) just because of the potential for newbie confusion 
 and/or the
 need to modify PATH, or leave one out of PATH and use an absolute path 
 for the
 other, etc..


 Symlinks doesn't work all the time, either. Some inferior file systems 
 (Win) and inferior package systems (Mac) needs to have copies instead...

 It would probably be easier to call it "gdmd", as suggested by David.
 Easy enough to add dmd as a local shell alias, if wanted by the user ?


Yes - I agree.. Just change the names of both the GDC driver script and 
library, so that nothing is duplicated for people installing both compilers.

- Dave
May 07 2005
prev sibling parent David Friedman <d3rdclsmail_a t_earthlink_d.t_net> writes:
Dave wrote:

 As a user of both DMD and GDC, I would like to request that some thought be put
 into renaming the GDC driver script (from dmd) and GDC libphobos to avoid
 conflicts.
 
 I know, there are several technical 'hacks' around this issue but the problem
is
 that the default installations of both DMD and GDC create the conflicts, and
the
 surest and cleanest way around that (especially for newbies) is to rename the
 as-installed script and library for GDC.
 
 I've hesitated for months to bring this up because I feared it could lead to
 some sort of a political battle, which I assure everyone is NOT my intent.
 However, there is a technical hurdle to overcome here and the simple fact of
the
 matter is that DMD was 'here first' if you will.
 
 As an aside, and given the general (if unwritten) rule about knowingly
'stepping
 on' other software installations, I've got to ask myself why this conflict was
 created in the first place. I apologize if this is a topic already covered. If
 so please point me to the archives..
 
 - Dave
 
 


The idea of the "dmd" script was to have drop-in replacement for the dmd 
command on systems that don't/can't have the original DMD distribution. 
  Unless both compilers were installed with prefix=/usr, there isn't an 
actual file conflict.  A specific compiler can be selected by changing 
the PATH.

I'm not saying this is *the way* to do things.  It's just the way I 
manage multiple GCC installations.  I'll think about installing "dmd" 
under another name as Anders suggests.

The library is a different issue.  I'll probably rename it to libgphobos.a.

David
May 06 2005