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