www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dtl - How to make and install DTL/MinTL

reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
I'm a hobby programmer - I write programs for fun and recreation. 
Usually they are truly simple things. And I've found D very expressive 
in that regard - I'd say I spend a lot less time programming the same 
quantity of program in D than in Java or C++.

But libraries in D - these things do me in. I mean, when programming in 
C++ any library is going to have its own little "how to install - cannot 
possibly fail" recipe in a small text file. It's quick and painless - 
type "make && make install" and you're set. You just include the 
relevant header file (which is already in the include path due to make 
install) and you're laughing.

I honestly cannot figure out how to use DTL/MinTL. Maybe I am 
unbelievably dumb - but a word of warning: If I can't figure this out; 
if this language becomes popular with completely new programmers (and it 
might be more attractive to them because it's a simpler language than 
for example C++) then this is going to become hell.

My question is simply: How am I supposed to build and install DTL/MinTL?

Everybody seems to have a different layout. DTLs makefile is riddled 
with SYNSOFT_ROOT (of which I have none), and obviously assumes that 
I've got things sorted in some specific order. MinTL hasn't got anything 
to help me at all. dmake (more hardcoded paths and general nausea from 
trying to figure out how to actually make it resolve paths, as in my 
case it was determined not to read sc.ini no matter what I did) just 
built 4-5 object files and linked it into my app, but when compiling 
with -unittest I got link errors (which to me are generally fairly greek).

Now, I'm sure DTL/MinTL will keep me very happy indeed. All I want is 
linked list. It shouldn't be this complicated.

I recall an old "Plug 'n' Play" joke: In D, it's more like "Plug 'n' 
Pray". At least for me. But I am quite possibly unbelievably dumb.

Cheers,
Sigbjørn Lund Olsen
Oct 17 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Sigbjørn Lund Olsen wrote:

 I'm a hobby programmer - I write programs for fun and recreation.
 Usually they are truly simple things. And I've found D very expressive
 in that regard - I'd say I spend a lot less time programming the same
 quantity of program in D than in Java or C++.
 
 But libraries in D - these things do me in. I mean, when programming in
 C++ any library is going to have its own little "how to install - cannot
 possibly fail" recipe in a small text file. It's quick and painless -
 type "make && make install" and you're set. You just include the
 relevant header file (which is already in the include path due to make
 install) and you're laughing.
 
 I honestly cannot figure out how to use DTL/MinTL. Maybe I am
 unbelievably dumb - but a word of warning: If I can't figure this out;
 if this language becomes popular with completely new programmers (and it
 might be more attractive to them because it's a simpler language than
 for example C++) then this is going to become hell.
 
 My question is simply: How am I supposed to build and install DTL/MinTL?
 
 Everybody seems to have a different layout. DTLs makefile is riddled
 with SYNSOFT_ROOT (of which I have none), and obviously assumes that
 I've got things sorted in some specific order. MinTL hasn't got anything
 to help me at all. dmake (more hardcoded paths and general nausea from
 trying to figure out how to actually make it resolve paths, as in my
 case it was determined not to read sc.ini no matter what I did) just
 built 4-5 object files and linked it into my app, but when compiling
 with -unittest I got link errors (which to me are generally fairly greek).
 
 Now, I'm sure DTL/MinTL will keep me very happy indeed. All I want is
 linked list. It shouldn't be this complicated.
 
 I recall an old "Plug 'n' Play" joke: In D, it's more like "Plug 'n'
 Pray". At least for me. But I am quite possibly unbelievably dumb.
 
 Cheers,
 Sigbjørn Lund Olsen

Near the end of the MinTL doc there is a section about "installing". What you do is add the containers you want plus the following: mintl/share.d mintl/seq.d (and it looks like mintl/array.d). So for example if the file mytest.d has import mintl.list; int main() { List!(int) list; list.add(10,20,30); return 0; } then it can be compiles with dmd mytest.d mintl/list.d mintl/share.d mintl/seq.d mintl/array.d The array.d is needed because of unittests - I should try to move those unittests elsewhere so that the dependencies are kept simple. The reason there isn't a makefile to make a library is that the lib would just contain a few exception classes - everything else is a template. I'll look into it, though, since it would be nice to trim down that list of stuff you need to type to get it to compile. If you get link errors like undefined reference to `_Class_5mintl5share25IndexOutOfBoundsException' then put mintl/share.d on the compilation list. It should be pretty easy to pick the module that is missing since it is mangled to "5mintl5share". Building with unittests might include more. Ignore any linker warnings about sizes of things being different - I get those all the time. They make me nervous but it doesn't seem to matter. I'll move that section about installing to the top of the doc so it is easier to find. Plus I notice that it leaves out mintl/array.d so I'll figure out what to do about that. good luck! -Ben
Oct 17 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
 The reason
 there isn't a makefile to make a library is that the lib would just
 contain a few exception classes - everything else is a template. I'll look
 into it, though, since it would be nice to trim down that list of stuff
 you need to type to get it to compile.

done.
 I'll move that section about installing to the top of the doc so it is
 easier to find. 

done.
Oct 17 2004
parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Ben Hinkle wrote:
 
The reason
there isn't a makefile to make a library is that the lib would just
contain a few exception classes - everything else is a template. I'll look
into it, though, since it would be nice to trim down that list of stuff
you need to type to get it to compile.

done.

Thanks. However: E:\Programs\dmd\src\mintl>make -f win32.mak make: *** No rule to make target `array.obj', needed by `mintl.lib'. Stop. You may want to add that one should be using DM make and not GNU make. Cheers, Sigbjørn Lund Olsen
Oct 17 2004
parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Sigbjørn Lund Olsen wrote:

 Ben Hinkle wrote:
 
 The reason
 there isn't a makefile to make a library is that the lib would just
 contain a few exception classes - everything else is a template. I'll 
 look
 into it, though, since it would be nice to trim down that list of stuff
 you need to type to get it to compile.

done.

Thanks. However: E:\Programs\dmd\src\mintl>make -f win32.mak make: *** No rule to make target `array.obj', needed by `mintl.lib'. Stop. You may want to add that one should be using DM make and not GNU make. Cheers, Sigbjørn Lund Olsen

I really must have the lowest IQ on the planet. I really, really, cannot figure out how to make it import the correct source files in any logical manner. I don't want to move my source to my mintl directories, nor do I want to move the mintl sources to my project directory - maybe I'm funny that way, but I don't have to do that when I use GCC, and I don't think it ought to be necessary to do it when I'm using DMD. In the end I did this: G:\docs\dev\ozip\ozip\lib\rle>dmd ac.d E:\programs\dmd\src\import\mintl\slist.d E:\programs\dmd\src\import\mintl\seq.d E:\programs\dmd\src\import\mintl\array.d E:\programs\dmd\src\import\mintl\share.d mintl.lib -unittest E:\Programs\dmd\bin\..\..\dm\bin\link.exe ac+slist+seq+array+share,,,mintl.lib+u ser32+kernel32/noi; Now I don't think that looks very pretty. There's something to the idea that for example you have an "include" (or say, an "import") directory somewhere under DMD_ROOT, and when you do "#include GL/glx.h" or "import mintl.slist.d" then the compiler automagically has a look there. I thought this was a bit of the idea with modules/packages mapping to files/folders anyway. Have I completely missed out on how I'm supposed to do this? Or is it simply not possible? *sigh* Cheers, Sigbjørn Lund Olsen
Oct 17 2004
next sibling parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Sigbjørn Lund Olsen wrote:

FYI:

import mintl.list;
int main ()
{
	List!(ubyte) res_list;
	res_list.add(10,20,30);
	return 0;
}

gives:

Error: Illegal item in mintl.share.add

Changing the ubyte to int makes it run nicely.

Cheers,
Sigbjørn Lund Olsen
Oct 17 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Sigbjørn Lund Olsen wrote:

 Sigbjørn Lund Olsen wrote:
 
 FYI:
 
 import mintl.list;
 int main ()
 {
 List!(ubyte) res_list;
 res_list.add(10,20,30);
 return 0;
 }
 
 gives:
 
 Error: Illegal item in mintl.share.add
 
 Changing the ubyte to int makes it run nicely.
 
 Cheers,
 Sigbjørn Lund Olsen

ahh - that's going to be a pain. Since add() is vararg it doesn't know 10,20,30 need to be ubytes instead of ints. I'll try putting some extra smarts in add() to look for int and try casting to the target type. Probably that would make sense for other types with implicit conversions. The work-around is to use res_list.add(cast(ubyte)10,cast(ubyte)20,cast(ubyte)30); or res_list ~= 10; res_list ~= 20; res_list ~= 30; both very ugly, I know.
Oct 17 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Sun, 17 Oct 2004 16:42:21 -0400, Ben Hinkle <bhinkle4 juno.com> wrote:
 Sigbjørn Lund Olsen wrote:

 Sigbjørn Lund Olsen wrote:

 FYI:

 import mintl.list;
 int main ()
 {
 List!(ubyte) res_list;
 res_list.add(10,20,30);
 return 0;
 }

 gives:

 Error: Illegal item in mintl.share.add

 Changing the ubyte to int makes it run nicely.

 Cheers,
 Sigbjørn Lund Olsen

ahh - that's going to be a pain. Since add() is vararg it doesn't know 10,20,30 need to be ubytes instead of ints. I'll try putting some extra smarts in add() to look for int and try casting to the target type. Probably that would make sense for other types with implicit conversions. The work-around is to use res_list.add(cast(ubyte)10,cast(ubyte)20,cast(ubyte)30); or res_list ~= 10; res_list ~= 20; res_list ~= 30; both very ugly, I know.

Can you change the signature of add to: void add(T one, ...) Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Oct 17 2004
prev sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
Sigbjørn Lund Olsen wrote:

 Sigbjørn Lund Olsen wrote:
 
 Ben Hinkle wrote:
 
 The reason
 there isn't a makefile to make a library is that the lib would just
 contain a few exception classes - everything else is a template. I'll
 look
 into it, though, since it would be nice to trim down that list of stuff
 you need to type to get it to compile.

done.

Thanks. However: E:\Programs\dmd\src\mintl>make -f win32.mak make: *** No rule to make target `array.obj', needed by `mintl.lib'. Stop. You may want to add that one should be using DM make and not GNU make. Cheers, Sigbjørn Lund Olsen

I really must have the lowest IQ on the planet. I really, really, cannot figure out how to make it import the correct source files in any logical manner. I don't want to move my source to my mintl directories, nor do I want to move the mintl sources to my project directory - maybe I'm funny that way, but I don't have to do that when I use GCC, and I don't think it ought to be necessary to do it when I'm using DMD. In the end I did this: G:\docs\dev\ozip\ozip\lib\rle>dmd ac.d E:\programs\dmd\src\import\mintl\slist.d E:\programs\dmd\src\import\mintl\seq.d E:\programs\dmd\src\import\mintl\array.d E:\programs\dmd\src\import\mintl\share.d mintl.lib -unittest E:\Programs\dmd\bin\..\..\dm\bin\link.exe ac+slist+seq+array+share,,,mintl.lib+u ser32+kernel32/noi; Now I don't think that looks very pretty. There's something to the idea that for example you have an "include" (or say, an "import") directory somewhere under DMD_ROOT, and when you do "#include GL/glx.h" or "import mintl.slist.d" then the compiler automagically has a look there. I thought this was a bit of the idea with modules/packages mapping to files/folders anyway. Have I completely missed out on how I'm supposed to do this? Or is it simply not possible? *sigh* Cheers, Sigbjørn Lund Olsen

yeah - I agree that is a pain. Any time you want to use a template with any asserts in it you have to spell it out on the dmd command line. At least that's the way it seems to me. One can use the -I option to add a path to the import lookup path but that doesn't handle template instantiations. Maybe we can get Walter's attention and he can think of something simpler. Here is an example: file foo1.d: module foo1; struct Foo(V) { invariant{ assert(true); } } file foo2.d module foo2; import foo1; int main() { Foo!(int) x; return 0; } compile with "dmd foo2.d" and you'll get an undefined ref to _assert_4foo1. If you take the assert out it works ok. If you compile with -release then it is also ok. A similar linking problem seems to happen when using mintl in the vararg mixin function add(). See the D.bugs list where I found with experimenting that the order of declarations fixes some linking bugs. I was also getting behavior that was hard to reproduce or didn't reproduce on win32 or linux. In general I've been quite frustrated trying to get complex mixin and module dependencies to link. It seems to be worse in dmd-102 but that is just a gut feeling. Anyway, any help reproducing linking problems would be appreciated because I think your experience will be typical. -Ben -Ben
Oct 17 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 17 Oct 2004 09:13:50 -0400, Ben Hinkle wrote:

 Sigbjørn Lund Olsen wrote:
 
 I'm a hobby programmer - I write programs for fun and recreation.
 Usually they are truly simple things. And I've found D very expressive
 in that regard - I'd say I spend a lot less time programming the same
 quantity of program in D than in Java or C++.
 
 But libraries in D - these things do me in. I mean, when programming in
 C++ any library is going to have its own little "how to install - cannot
 possibly fail" recipe in a small text file. It's quick and painless -
 type "make && make install" and you're set. You just include the
 relevant header file (which is already in the include path due to make
 install) and you're laughing.
 
 I honestly cannot figure out how to use DTL/MinTL. Maybe I am
 unbelievably dumb - but a word of warning: If I can't figure this out;
 if this language becomes popular with completely new programmers (and it
 might be more attractive to them because it's a simpler language than
 for example C++) then this is going to become hell.
 
 My question is simply: How am I supposed to build and install DTL/MinTL?
 
 Everybody seems to have a different layout. DTLs makefile is riddled
 with SYNSOFT_ROOT (of which I have none), and obviously assumes that
 I've got things sorted in some specific order. MinTL hasn't got anything
 to help me at all. dmake (more hardcoded paths and general nausea from
 trying to figure out how to actually make it resolve paths, as in my
 case it was determined not to read sc.ini no matter what I did) just
 built 4-5 object files and linked it into my app, but when compiling
 with -unittest I got link errors (which to me are generally fairly greek).
 
 Now, I'm sure DTL/MinTL will keep me very happy indeed. All I want is
 linked list. It shouldn't be this complicated.
 
 I recall an old "Plug 'n' Play" joke: In D, it's more like "Plug 'n'
 Pray". At least for me. But I am quite possibly unbelievably dumb.
 
 Cheers,
 Sigbjørn Lund Olsen

Near the end of the MinTL doc there is a section about "installing". What you do is add the containers you want plus the following: mintl/share.d mintl/seq.d (and it looks like mintl/array.d). So for example if the file mytest.d has import mintl.list; int main() { List!(int) list; list.add(10,20,30); return 0; } then it can be compiles with dmd mytest.d mintl/list.d mintl/share.d mintl/seq.d mintl/array.d The array.d is needed because of unittests - I should try to move those unittests elsewhere so that the dependencies are kept simple. The reason there isn't a makefile to make a library is that the lib would just contain a few exception classes - everything else is a template. I'll look into it, though, since it would be nice to trim down that list of stuff you need to type to get it to compile. If you get link errors like undefined reference to `_Class_5mintl5share25IndexOutOfBoundsException' then put mintl/share.d on the compilation list. It should be pretty easy to pick the module that is missing since it is mangled to "5mintl5share". Building with unittests might include more. Ignore any linker warnings about sizes of things being different - I get those all the time. They make me nervous but it doesn't seem to matter. I'll move that section about installing to the top of the doc so it is easier to find. Plus I notice that it leaves out mintl/array.d so I'll figure out what to do about that. good luck! -Ben

I tried to compile this too. But the linkage failed. C:\dparnell\D_Proj\mintl>dmd test.d mintl/list.d mintl/share.d mintl/seq.d mintl/array.d C:\DPARNELL\DMD\BIN\..\..\dm\bin\link.exe test+list+share+seq+array,,,user32+kernel32/noi; OPTLINK (R) for Win32 Release 7.50B1 Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved test.obj(test) Error 42: Symbol Undefined _init_10TypeInfo_i --- errorlevel 1 -- Derek Melbourne, Australia 18/10/2004 9:18:30 AM
Oct 17 2004
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
[snip]
 I tried to compile this too. But the linkage failed.

 C:\dparnell\D_Proj\mintl>dmd test.d mintl/list.d mintl/share.d mintl/seq.d
 mintl/array.d
 C:\DPARNELL\DMD\BIN\..\..\dm\bin\link.exe
 test+list+share+seq+array,,,user32+kernel32/noi;
 OPTLINK (R) for Win32  Release 7.50B1
 Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

 test.obj(test)
  Error 42: Symbol Undefined _init_10TypeInfo_i
 --- errorlevel 1

Hmm. For me it works on Linux and Windows but when I try with the -unittest flag on Windows I get list.obj(list) Error 42: Symbol Undefined _init_10TypeInfo_a list.obj(list) Error 42: Symbol Undefined _init_11TypeInfo_Aa list.obj(list) Error 42: Symbol Undefined _init_10TypeInfo_i --- errorlevel 3 There could be some issue about __init vs _init. See also digitalmars.D.bugs/1904 and digitalmars.D.bugs/1946 -Ben
Oct 18 2004
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
 Everybody seems to have a different layout. DTLs makefile is riddled with
SYNSOFT_ROOT (of which I have none), and 
 obviously assumes that I've got things sorted in some specific order.

My fault, not yours. (I didn't realise that that was the case - I thought it was all relative.) DTL 0.3 will be coming as soon as I've got 15 million things sorted, and will have a sensible makefile.
 Now, I'm sure DTL/MinTL will keep me very happy indeed. All I want is linked
list. It shouldn't be this complicated.

It shouldn't. DTL is currently floundering at the end of a list. If there's anyone's left who's interested when I get round to doing the next round, things should be significantly better. Matthew
Oct 18 2004