www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Module packaging

reply Thiago <talexbh gmail.com> writes:
Good morning,

it could be useful on D a packaging system like Python's 'dist-utils', and
setting a default folder to put library source (i.e. phobos /src, etc...)? 

I think a similar system could be useful on D, by reducing (or even avoiding) a
lot of of -I flags needed to compilation and installation (just download the
package and run a command like 'dmd-install'), and so on.

Someone could tell me if such system already exists? If not, its creation would
be a good idea?

Thanks,

Thiago
May 16 2007
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Thiago wrote:


 Someone could tell me if such system already exists? If not, its creation
would be a good idea?


See http://dsource.org/projects/dsss/, the "D Shared Software System"

You can also use normal packaging for C/C++ etc. I normally install the 
import modules in $PREFIX/include/d and the libraries in $PREFIX/lib...

--anders
May 16 2007
parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Anders F Björklund wrote:

 Thiago wrote:
 

 Someone could tell me if such system already exists? If not, its 
 creation would be a good idea?


 
 See http://dsource.org/projects/dsss/, the "D Shared Software System"
 
 You can also use normal packaging for C/C++ etc. I normally install the 
 import modules in $PREFIX/include/d and the libraries in $PREFIX/lib...
 
 --anders


I think he refers to a standard folder where a library can be dropped 
and it's included by the compiler automatically.
May 16 2007
parent reply Justin C Calvarese <technocrat7 gmail.com> writes:
Julio César Carrascal Urquijo wrote:

 Anders F Björklund wrote:

 Thiago wrote:


 Someone could tell me if such system already exists? If not, its 
 creation would be a good idea?


 See http://dsource.org/projects/dsss/, the "D Shared Software System"

 You can also use normal packaging for C/C++ etc. I normally install 
 the import modules in $PREFIX/include/d and the libraries in 
 $PREFIX/lib...

 --anders


 
 I think he refers to a standard folder where a library can be dropped 
 and it's included by the compiler automatically.


Just for fun, let's take a survey.

I can't decide where to store my code. On my home computer I've been 
using "C:\pgm\d\src", but on my work computer, I've been using 
"D:\MyFiles\pgm\d\src".

I suspect at least one person is using "C:\dmd\src" (or something similar).

But I have multiple versions of DMD on my comptuer, so I guess I would 
have to decide between:
C:\PrgFiles\dmd-1.000\src
C:\PrgFiles\dmd-1.007\src
C:\PrgFiles\dmd-1.013\src
etc.


-- 
jcc7
May 17 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to Justin,


 Julio César Carrascal Urquijo wrote:
 

 Anders F Björklund wrote:
 

 Thiago wrote:
 

 Someone could tell me if such system already exists? If not, its
 creation would be a good idea?
 


 See http://dsource.org/projects/dsss/, the "D Shared Software
 System"
 
 You can also use normal packaging for C/C++ etc. I normally install
 the import modules in $PREFIX/include/d and the libraries in
 $PREFIX/lib...
 
 --anders
 


 I think he refers to a standard folder where a library can be dropped
 and it's included by the compiler automatically.
 


 Just for fun, let's take a survey.
 
 I can't decide where to store my code. On my home computer I've been
 using "C:\pgm\d\src", but on my work computer, I've been using
 "D:\MyFiles\pgm\d\src".
 
 I suspect at least one person is using "C:\dmd\src" (or something
 similar).
 
 But I have multiple versions of DMD on my comptuer, so I guess I would
 have to decide between:
 C:\PrgFiles\dmd-1.000\src
 C:\PrgFiles\dmd-1.007\src
 C:\PrgFiles\dmd-1.013\src
 etc.


/My/ source is all over the place. it is all intended to be found using the 
"current directory as root" approach. 3rd party libs on the other hand, I 
have recently decided that on win32 to put them in a c:\dsrc\ directory (I'm 
sure I am remembering the name is wrong but who cares). This is because I 
have DMD installed under c:\dmd\ and just rename that and extract the new 
dmd for each new release. However on linux I have a script to dump stuff 
all over the place so putting libs beside the phobos source isn't a problem.
May 17 2007
prev sibling next sibling parent Gregor Richards <Richards codu.org> writes:
Justin C Calvarese wrote:

 Julio César Carrascal Urquijo wrote:

 Anders F Björklund wrote:

 Thiago wrote:


 Someone could tell me if such system already exists? If not, its 
 creation would be a good idea?


 See http://dsource.org/projects/dsss/, the "D Shared Software System"

 You can also use normal packaging for C/C++ etc. I normally install 
 the import modules in $PREFIX/include/d and the libraries in 
 $PREFIX/lib...

 --anders


 I think he refers to a standard folder where a library can be dropped 
 and it's included by the compiler automatically.


 
 Just for fun, let's take a survey.
 
 I can't decide where to store my code. On my home computer I've been 
 using "C:\pgm\d\src", but on my work computer, I've been using 
 "D:\MyFiles\pgm\d\src".
 
 I suspect at least one person is using "C:\dmd\src" (or something similar).
 
 But I have multiple versions of DMD on my comptuer, so I guess I would 
 have to decide between:
 C:\PrgFiles\dmd-1.000\src
 C:\PrgFiles\dmd-1.007\src
 C:\PrgFiles\dmd-1.013\src
 etc.
 
 


Wouldn't it be great if somebody made a system that could install your D 
source to some central location, and then allow you to use it easily, 
without adding a bunch of -I and -L directives? Oh well, too bad nobody 
has ever thought to do that.

  - Gregor Richards

PS: In case you didn't get it: I'm talking about DSSS, stupid.
May 17 2007
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Justin C Calvarese wrote:


 I can't decide where to store my code. On my home computer I've been 
 using "C:\pgm\d\src", but on my work computer, I've been using 
 "D:\MyFiles\pgm\d\src".


I don't use my code from the source directory, I use it from the
install directory. So there's a global -I and -L in effect already.

Usually /usr/local/include/d and /usr/local/lib, as was mentioned.
No idea what path I would use under Windows, probably DSSS instead.

--anders
May 17 2007
prev sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Justin C Calvarese wrote:

 Julio César Carrascal Urquijo wrote:

 Anders F Björklund wrote:

 Thiago wrote:


 Someone could tell me if such system already exists? If not, its 
 creation would be a good idea?


 See http://dsource.org/projects/dsss/, the "D Shared Software System"

 You can also use normal packaging for C/C++ etc. I normally install 
 the import modules in $PREFIX/include/d and the libraries in 
 $PREFIX/lib...

 --anders


 I think he refers to a standard folder where a library can be dropped 
 and it's included by the compiler automatically.


 
 Just for fun, let's take a survey.
 
 I can't decide where to store my code. On my home computer I've been 
 using "C:\pgm\d\src", but on my work computer, I've been using 
 "D:\MyFiles\pgm\d\src".
 
 I suspect at least one person is using "C:\dmd\src" (or something similar).
 
 But I have multiple versions of DMD on my comptuer, so I guess I would 
 have to decide between:
 C:\PrgFiles\dmd-1.000\src
 C:\PrgFiles\dmd-1.007\src
 C:\PrgFiles\dmd-1.013\src
 etc.
 
 


I take a two-pronged approach under Windows.

First off I have a DMD installation \bin directory on the current %PATH%, that
contains any libraries I use frequently 
tucked away under that installation's include path.  I recently moved from
Phobos to Tango, so this was under 
c:\programs\dmd and is now under c:\programs\tango.  I have rebuild and bud
installed side-by-side with dmd.exe, with 
one or the other copied to "build.exe".  This makes it easy to switch build
tools if need be.

Then, when doing development I do all my builds from that project's root, with
any secondary libraries (code that's 
experimental, beta, patched by me, unstable, etc.) dumped in that directory. 
This way I keep the main include path free 
from such clutter and thus, projects don't interfere with each other should
they have common dependencies.

I do *not* use pre-compiled libraries in any of my development, save phobos.lib
and tango.lib.  DMD and OPTLINK are so 
damn fast that there's no point for open projects.  Since bud/rebuild are less
sophisticated than make (can't associate 
a lib build with its dependencies to trigger a sub-build), I find that this is
almost necessary in some cases.  As it 
happens, it also makes things very easy to hack should the need arise.

I've never used multiple versions of DMD, but if I had to, I'd probably rename
my install dir and install the secondary 
compiler in it's place - renaming directories as needed.

While we're on the topic, my Linux setup is a little more conventional.

I followed the install instructions on the Wiki for Phobos, and I'll be
shifting to Tango soon via the installer.  I 
typically only use it for VNV* to ensure that my stuff is portable and
deployable.  I simply re-extract the current 
project via SVN, as any of you would, and try to build against it.  Changes are
made locally and re-submitted to SVN to 
be re-checked in windows the same way.

Using SVN like that may sound kind of crazy, but I've caught quite a few
missing files in the repository this way.

Also, FWIW, I've taken to using BASH scripts for larger build tasks in both
Windows and Linux.  The Win32 port of the 
GNU Linux shell utilities (sh, ls, find, grep, and more) makes this a snap and
is *highly* recommended for anyone who 
works in both systems frequently.

(*not the band "VNV Nation", although they're cool; I mean "Verifcation aNd
Validation")

-- 
- EricAnderton at yahoo
May 17 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Pragma,


 I simply
 re-extract the current project via SVN, as any of you would, and try
 to build against it.  Changes are made locally and re-submitted to SVN
 to be re-checked in windows the same way.
 
 Using SVN like that may sound kind of crazy, but I've caught quite a
 few missing files in the repository this way.
 


IMHO, it is the only sane way to transfer projects and the like back and 
forth between systems.


 Also, FWIW, I've taken to using BASH scripts for larger build tasks in
 both Windows and Linux.  The Win32 port of the GNU Linux shell
 utilities (sh, ls, find, grep, and more) makes this a snap and is
 *highly* recommended for anyone who works in both systems frequently.
 


where do you get these? (Do you have a link handy?)
May 17 2007
parent reply Sean Kelly <sean f4.ca> writes:
BCS wrote:

 Reply to Pragma,

 Also, FWIW, I've taken to using BASH scripts for larger build tasks in
 both Windows and Linux.  The Win32 port of the GNU Linux shell
 utilities (sh, ls, find, grep, and more) makes this a snap and is
 *highly* recommended for anyone who works in both systems frequently.


 
 where do you get these? (Do you have a link handy?)


http://gnuwin32.sourceforge.net/

There's an installer script on that site somewhere that's the easiest 
way to get things.  Uncompressed, the resulting mess is about 350MB, 
though much of that could be deleted, just keeping the binaries.


Sean
May 17 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:

 BCS wrote:

 Reply to Pragma,

 Also, FWIW, I've taken to using BASH scripts for larger build tasks in
 both Windows and Linux.  The Win32 port of the GNU Linux shell
 utilities (sh, ls, find, grep, and more) makes this a snap and is
 *highly* recommended for anyone who works in both systems frequently.


 where do you get these? (Do you have a l ink handy?)


 
 http://gnuwin32.sourceforge.net/
 
 There's an installer script on that site somewhere that's the easiest 
 way to get things.  Uncompressed, the resulting mess is about 350MB, 
 though much of that could be deleted, just keeping the binaries.


Do those versions of the gnu tools work happily with both forward slash 
and backslash?  MSYS annoyingly only accepts fwd slashes which makes 
using the tools from a CMD prompt annoying.

--bb
May 17 2007
parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:

 Sean Kelly wrote:

 BCS wrote:

 Reply to Pragma,

 Also, FWIW, I've taken to using BASH scripts for larger build tasks in
 both Windows and Linux.  The Win32 port of the GNU Linux shell
 utilities (sh, ls, find, grep, and more) makes this a snap and is
 *highly* recommended for anyone who works in both systems frequently.


 where do you get these? (Do you have a l ink handy?)


 http://gnuwin32.sourceforge.net/

 There's an installer script on that site somewhere that's the easiest 
 way to get things.  Uncompressed, the resulting mess is about 350MB, 
 though much of that could be deleted, just keeping the binaries.


 
 Do those versions of the gnu tools work happily with both forward slash 
 and backslash?  MSYS annoyingly only accepts fwd slashes which makes 
 using the tools from a CMD prompt annoying.


They do.  Or at least the few I've tried do.


Sean
May 18 2007
prev sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Sean Kelly wrote:

 BCS wrote:

 Reply to Pragma,

 Also, FWIW, I've taken to using BASH scripts for larger build tasks in
 both Windows and Linux.  The Win32 port of the GNU Linux shell
 utilities (sh, ls, find, grep, and more) makes this a snap and is
 *highly* recommended for anyone who works in both systems frequently.


 where do you get these? (Do you have a link handy?)


 
 http://gnuwin32.sourceforge.net/
 
 There's an installer script on that site somewhere that's the easiest 
 way to get things.  Uncompressed, the resulting mess is about 350MB, 
 though much of that could be deleted, just keeping the binaries.
 
 
 Sean


Actually, I just use these: http://unxutils.sourceforge.net/ (*way* smaller
than 350MB).

The only problem with installing that I've had is that find.exe already exists
under c:\windows, so you need to put the 
/bin directories for this at the *start* of your system path.  Otherwise, you
can't use the unix-style 'find' command, 
but everything else still works.

The Windows/DOS shell isn't as crippled as you'd think, it just doesn't have
any good commands.  The utils are 
non-backslash friendly, but as the DMD tools are *forward-slash* friendly, I
just quit using backslashes altogether.

Rebuild has a small issue with forward-slashes on Windows though. :(

-- 
- EricAnderton at yahoo
May 18 2007
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
Thiago,
I use common approach:
- system-wide installation of module(s) goes into /usr/include/d
- user's own installation of module(s) go into $HOME/include/d .

I believe many D developers use the same approach.

Kind regards
Dejan
May 18 2007