Ty Tower wrote:
> Lars Ivar Igesund Wrote:
>>> Don't start on me ! I am still here and contributing with posts wherever I see stupidity, 
>> Contributing more stupidity?
> 
> Now you see Lars here be your way, and your error.
> Attack the messenger and ignore the message We all fall into it from time to time but you do it regularly whenever someone says anything negative.

If a messenger repeatedly attacked me, I'd start attacking the messenger and ignoring the message.

Reply to Chris,

> BCS wrote:
> 
>> Reply to Chris,
>> 
>>> UML class diagrams and UML sequence diagrams are not design; they
>>> are programming. Programming in a language with no compiler,
>>> programming without including your core algorithms, programming
>>> without any tests. There's no way in hell you can verify your design
>>> will be even remotely close to something that can work.
>>> 
>>> You can safely and usefully design at a higher level before writing
>>> any code, but not on the class level.
>>> 
>> I beg to differ. The one and only time I used UML it was very useful.
>> It helped me track a number of aspects of the design and brought to
>> light a number of deficiencies. I'd say UML is a design "tool" but in
>> the way that Word or a pad of paper can be, as an aid to
>> documentation.
>> 
> You were using UML class diagrams. Were you generating code from UML,
> or UML from code?
> 

Not yet. The project the design was for got back burnered so no actual code has been written yet.

Aside: I've though it might be interesting to do a mid size project where the only people allowed to touch the actual code are interns. The "real" programmers are only allowed to work on the spec and design. But they are allowed to design to the point their there really isn't anything left that a C average CS sophomore couldn't handle.

> If you want to use UML to document existing code, that has always
> sounded like a good idea to me. You don't have to wade through code
> and comments to get an idea of what's going on. But in this case, you
> MUST use UML that's autogenerated from your code. Otherwise, your UML
> documentation will branch away from your code.
> 

The other option is to fully generate the code from the UML. Either way one is golden and the other is generated.

"Chris Wright" <dhasenan@gmail.com> wrote in message news:g116kf$2sjl$1@digitalmars.com...
> Clay Smith wrote:
>> Chris R. Miller wrote:
>>> A very good friend of mine and an absolutely fantastic programmer once told me some great advice: stop making stupid UML diagrams and write code!
>>>
>>
>> Sorry, but I have to say that you are not getting great advice. The design stage is the most important stage in the life of a program. Get that wrong and you can write all the code you want, and it will all be wrong.
>
> UML class diagrams and UML sequence diagrams are not design; they are programming. Programming in a language with no compiler, programming without including your core algorithms, programming without any tests. There's no way in hell you can verify your design will be even remotely close to something that can work.
>
> You can safely and usefully design at a higher level before writing any code, but not on the class level.

Safely, yes, usefully, maybe ;)

I'm convinced highly iterative development for anything even remotely complex is where it's at, so it's easy to spend too much time on the initial design stage, IMHO. I've seen too many projects that were over-designed prior to any coding that have failed miserably, mostly because what the user thinks they want and what they really want (once they start using something) are totally different.

A great example is the development of the language and tools for D itself <g>

Reply to Dave,

> it's easy to spend too much time on the
> initial design stage, IMHO. I've seen too many projects that were
> over-designed prior to any coding that have failed miserably

I think the important thing is to keep in mind what the design gives you and what it costs you.

The design is a tool for making better software. It lets you catch some design flaws earlier and fix them when it's cheaper. But it can be a costly way to find types of bugs. So when the cost savings of finding the bug that way exceeds the cost savings of fixing it later, just implement the sucker.

I suspect that's why formal design is more common in airplanes and space probes, finding a bug in flight control code by waiting for the plain to crash (pun) is kind of expensive.

Sean Kelly Wrote:
[...]
> I agree with your comment on tools and libraries in general, but D does already have a solid
> install/update/build tool in DSSS/rebuild.  With it, installing supported packages is as simple
> as "dsss net install blah", which I believe is roughly equivalent to ruby gems or whatever you
> used there instead.  Regarding DB support, I think some branch of DDBI may actually build
> with the current version of D, but you're right that it doesn't receive a lot of attention.
> Unfortunately, D is still very much a language for self-starters, and the overarching focus
> on newer and more features rather than building a solid base for development probably
> doesn't help things either.  Overall, the trend seems to be a churn of new users rather than
> a growing group of serious professionals--likely for these reasons.  That said, there are
> more than a few professional developers which have found a development environment
> which suits them--from my experience it tends to be DMD/Linux and Tango with either
> makefiles or DSSS for building and GDB with the demangling patch for debugging.

Thanks to all for the (mostly) thoughtful comments on this issue.  I have tried again, this time documenting my steps, to more thouroughly illustrate what I am going through.  Here is a more-or-less verbatim run of my efforts to get dbi compiled and installed.  To say the least, the results are less than satisfying:
Download and install d 1.030.

Go to D web site to find OBI component.  Look for something that
indicates "tools", or "libraries" for D.  See "Tools" section.
Look in "More Tools" link.  Nothing there, so back to the
main page.  Look under "Community"/"D links".  Looks good.
Using Firebugs, search for "Database" on the page.  Find D DBI.
Ok, click it.

Look for "downloads".  Find "Recommended" is "Version 0.2.5", so download that to my build directory and unzip the zip file.

Look for and find doc on "HowToBuild".  It says:

The current recommended way to build dbi.lib is to use buildme.d. It comes in the directory below dbi.

To build a release version of D DBI with every module, use any of the following:

    dmd -run buildme.d all

So, I try the first command:

% cd tags/0.2.5
% dmd -run buildme.d all
buildme.d: module buildme cannot read file 'buildme.d'

So, it fails because it cannot read the file.  So, I figure out why:

ls -l
total 28
----------  1 rael rael 4478 2007-02-03 01:21 buildme.d
drwxr-xr-x 10 rael rael 4096 2008-05-28 15:02 dbi drwxr-xr-x  3 rael rael 4096 2008-05-28 15:02 docs

It has unzipped things with no read permissions.  So, I fix it and try again:

% chmod +rw buildme.d
% dmd -run buildme.d all
buildme.d(42): module FileConst cannot read file 'tango/io/FileConst.d'

With no clue as to what this means, I read the source file buildme.d, and discover that it appears to support two versions, Phobos, and something else, presumably Tango.  So, I read the dmd doc to see how to set this flag (dmd -Dversion=Phobos didn't work).  Finding that, I try again, and fail again:

% dmd -version=Phobos -run buildme.d all
sh: bud: command not found

So, I try to find bud.  I go back to the dlinks page and find it and download it, and attempt to build IT:

% cd bud-3.04

The instructions say:

If you have no existing binary, the executable must be built with the makefile first:

make -f Makefile.unix

So, I try that:

% make -f Makefile.unix
make: Makefile.unix: No such file or directory
make: *** No rule to make target `Makefile.unix'.  Stop.

Ah, ok.  Let's see what's wrong now:

% ls
Source

Ok, would have been nice to document that, but forging ahead...

% cd Source
% make -f Makefile.unix
dmd -op -release -inline -ofbuild build.d util/pathex_bn.d util/pathex.d source_bn.d util/str.d build_bn.d util/booltype.d util/fdt_bn.d util/str_bn.d source.d util/fdt.d util/fileex.d util/fileex_bn.d util/linetoken.d util/linetoken_bn.d util/macro.d util/file2.d
build.d(56): Identifier expected following package
build.d(56): ';' expected
build.d(634): identifier expected following '.', not 'macro'
build.d(3348): identifier expected following '.', not 'macro'
source.d(55): Identifier expected following package
source.d(55): ';' expected
source.d(105): Identifier expected following package
source.d(105): ';' expected
source.d(483): identifier expected following '.', not 'macro'
util/macro.d(38): Identifier expected following package
make: *** [build] Error 1

So, the build tool itself advertised to build the tool I want to use fails to build.  Irony...

So, I discover after a long set of searches and guess on my part that 'util.macro' should perhaps be 'util.Macro'.  I make those substitutions in the bud source code and the build of it finally works:

% make -f Makefile.unix
dmd -op -release -inline -ofbuild build.d util/pathex_bn.d util/pathex.d source_bn.d util/str.d build_bn.d util/booltype.d util/fdt_bn.d util/str_bn.d source.d util/fdt.d util/fileex.d util/fileex_bn.d util/linetoken.d util/linetoken_bn.d util/macro.d util/file2.d

Noting that the bud build instructions also say:

It is still imperative to build a final binary with the utility itself:

    ./build build -full -op
    ln -s build bud

So:

% ./build build -full -op
Source.d(55): module Macro cannot read file 'util/Macro.d'

Of course not.  So, I move util/macro.d to util/Macro.d:

% mv util/macro.d util/Macro.d

try again:

% ./build build -full -op
/usr/bin/ld: skipping incompatible /usr/lib/libphobos.a when searching for -lphobos
/usr/bin/ld: cannot find -lphobos
collect2: ld returned 1 exit status

Usure how a freshly installed libphobos.a from the freshly installed dmd package could be a problem:

% which dmd
/opt/dmd/bin/dmd
% ls -l /opt/dmd/lib/libphobos.a
-rw-r--r-- 1 rael rael 1344630 2008-05-16 23:01 /opt/dmd/lib/libphobos.a
% ls -l /usr/lib/libphobos.a
-rw-r--r-- 1 root root 1344630 2008-05-28 14:17 /usr/lib/libphobos.a
% cmp /opt/dmd/lib/libphobos.a /usr/lib/libphobos.a
% echo $?
0

So, the files are identical...

Oh, and here's another cool thing:

% ls -l build
ls: cannot access build: No such file or directory

So, the build failure erases the build file itself.  Very, very cool.

So, rebuild from makefile:

% make -f Makefile.unix
make: *** No rule to make target `util/macro.d', needed by `build'.  Stop.

Of course.  So, I link util/Macro.d to util/macro.d:

% cd util/
% ln -s Macro.d macro.d
% cd ..
% make -f Makefile.unix
dmd -op -release -inline -ofbuild build.d util/pathex_bn.d util/pathex.d source_bn.d util/str.d build_bn.d util/booltype.d util/fdt_bn.d util/str_bn.d source.d util/fdt.d util/fileex.d util/fileex_bn.d util/linetoken.d util/linetoken_bn.d util/macro.d util/file2.d

And now, move build to something else, perhaps?:

% mv build buildit
% ./buildit build -full -op
/usr/bin/ld: skipping incompatible /usr/lib/libphobos.a when searching for -lphobos
/usr/bin/ld: cannot find -lphobos
collect2: ld returned 1 exit status

And now I discover that since I have a 64-bit machine, perhaps I am just totally hosed?

dmd itself seems to work fine:

% cd /opt/dmd/samples/d/
% dmd wc.d
% echo "Hello world" | ./wc
% ./wc wc.d
   lines   words   bytes file
      45      80     810 wc.d

So, what the hell, I'll try with the version of bud built from the makefile and see if that is good enough:

% cp buildit ~/bin
% cd /build/tags/0.25
% dmd -version=Phobos -run buildme.d all
Error: dbi/all.d: Permission denied

Lovely, more permissions errors:

% ls -l dbi/all.d
---------- 1 rael rael 250 2007-02-03 01:21 dbi/all.d

So, fix them:

% find . -type f | xargs chmod +rw

and try again:

%  dmd -version=Phobos -run buildme.d all
dbi/oracle/imp/orl.d(1147): found 'ref' when expecting ')'
dbi/oracle/imp/orl.d(1147): semicolon expected following function declaration
dbi/oracle/imp/orl.d(1147): Declaration expected, not ')'
dbi/oracle/imp/orl.d(1188): found 'ref' when expecting ')'
dbi/oracle/imp/orl.d(1188): semicolon expected following function declaration
dbi/oracle/imp/orl.d(1188): Declaration expected, not ')'
dbi/oracle/imp/orl.d(1200): found 'ref' when expecting ')'
dbi/oracle/imp/orl.d(1200): semicolon expected following function declaration
dbi/oracle/imp/orl.d(1200): Declaration expected, not ')'
dbi/oracle/imp/orl.d(1216): found 'ref' when expecting ')'
dbi/oracle/imp/orl.d(1216): semicolon expected following function declaration
dbi/oracle/imp/orl.d(1216): Declaration expected, not ')'
dbi/oracle/imp/orl.d(1231): found 'ref' when expecting ')'
dbi/oracle/imp/orl.d(1231): semicolon expected following function declaration
dbi/oracle/imp/orl.d(1231): Declaration expected, not ','
dbi/oracle/imp/ori.d(404): found 'ref' when expecting ')'
dbi/oracle/imp/ori.d(404): semicolon expected following function declaration
dbi/oracle/imp/ori.d(404): Declaration expected, not ')'
dbi/oracle/imp/ori.d(1106): found 'ref' when expecting ')'
dbi/oracle/imp/ori.d(1106): semicolon expected following function declaration
dbi/oracle/imp/ori.d(1106): Declaration expected, not ')'

Ok, it's building oracle.  I don't really want oracle.  The code says I can pass '-mysql'.  Try that:

% dmd -version=Phobos -run buildme.d -mysql
Error: Invalid argument "-mysql."  "mysql" isn't on the list of DBDs to build.

Try again:

% dmd -version=Phobos -run buildme.d mysql

Hmm, no errors, no nothing.  What did it do?

% ls -lt
total 36
drwxr-xr-x 10 rael rael 4096 2008-05-28 16:03 dbi
drwxr-xr-x  2 rael rael 4096 2008-05-28 16:03 libddbi.a
drwxr-xr-x  3 rael rael 4096 2008-05-28 15:52 docs
-rw-r--r--  1 rael rael 4478 2007-02-03 01:21 buildme.d

% ls -l libddbi.a/
total 0
% ls -lt dbi/
total 264
-rw-r--r-- 1 rael rael 124890 2008-05-28 16:03 all.a
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 ib
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 msql
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 mssql
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 mysql
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 odbc
drwxr-xr-x 3 rael rael   4096 2008-05-28 15:52 oracle
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 pg
drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 sqlite
-rw-r--r-- 1 rael rael    250 2007-02-03 01:21 all.d
-rw-r--r-- 1 rael rael   5813 2007-02-03 01:21 Database.d
-rw-r--r-- 1 rael rael   2658 2007-02-03 01:21 DBIException.d
-rw-r--r-- 1 rael rael   2500 2007-02-03 01:21 ErrorCode.d
-rw-r--r-- 1 rael rael   1192 2007-02-03 01:21 Result.d
-rw-r--r-- 1 rael rael   4194 2007-02-03 01:21 Row.d
-rw-r--r-- 1 rael rael   6736 2007-02-03 01:21 Statement.d

Hm, ok, we have an 'all.a' file and some .d files, so presumably
we'll have to install these somewhere.  No clue if it actually
built what I wanted ... There is no install
target, it appears (thank goodness we're not using make!).  So, we
look for example code on the web site:

Another recommended way to learn how to use D DBI is to look at the unittests in the SqliteDatabase file.

When I click on the link:

Internal Server Error

500 Internal Server Error (No node /trunk/dbi/sqlite/sqlitedatabase.d at
revision 91<br><p>You can <a
href="/projects/ddbi/log/trunk/dbi/sqlite/sqlitedatabase.d?rev=91&amp;mode=path_history">search</a>
in the repository history to see if that path existed but was later
removed.</p>)

Oops...

So, I try to run the unit test code.  Guessing:

% dmd -version=Phobos -run dbi/mysql/MysqlDatabase.d dbi/all.a -lmysqlclient [big fat failure]

Try again:

%  dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a -lmysqlclient Error: unrecognized switch '-lmysqlclient'

and again:

% dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a [... vast spewage ...]

Well, ok, try again:

% dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a -L'-L/usr/lib/mysql -lmysqlclient'

and more failures.

Try again:

% dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a /usr/lib/mysql/libmysqlclient.a

Well, it gets by the undefined references to mysql internals, but of course new undefined errors show up.

[More tail chasing elided here for sake of space.]

At this point, I've wasted, not "20 minutes" as claimed here, but a solid 2 1/2 hours of my time.

I do hope others realize that I have gone to the trouble to document this not to impugn anyone's motives, but to provide what I think is a valuable service to the D community, while at the same time declining to join said community due to professional and personal time constraints.

Perhaps I'll return to this effort tomorrow and see if I can kick it along any further, but I rather doubt I will, as even if I do get the thing to compile, my confidence in the entire body of code is so low that I am loathe to recommend that our development group even consider it for production-ready code.

Some observations:

1) Using "yet another make system" to build dbi seems of dubious benefit.

2) Even the most basic issues do not go well --- the source code wouldn't even unzip properly.

3) If users are to adopt D, then the support universe around it needs to be strengthened.  Anything more than a few keystrokes' to install something is going to turn away potential legions of followers.  I'd like to see this:

% dinstall dbi
DBI is now installed for D.  Have fun.

And I think that is a reasonable goal to aim for.

As I said, I just don't have the time presently to contribute any more than I have to this, and I hope this will help the D community in some way.

Thanks.


Bill

Bill Lear wrote:
> Thanks to all for the (mostly) thoughtful comments on this issue.  I
> have tried again, this time documenting my steps, to more thouroughly
> illustrate what I am going through.  Here is a more-or-less verbatim
> run of my efforts to get dbi compiled and installed.  To say the
> least, the results are less than satisfying:

Thanks for taking the time and effort to document what is going wrong. This is very valuable information.

On Wed, 28 May 2008 22:44:14 +0100, Bill Lear <rael@zopyra.com> wrote:

[Too much to usefully summarise...]

It sounds like one problem is that this DBI package is being maintained mostly on Windows.
The case sensitivity issues are a dead give away. This would also explain the permissions
problems and probably the library ones too.
You are effectively doing the porting work for this package so its no surprise you are
struggling to get something up and running quickly. Porting something when you are working
with a known toolchain is one thing but doing it with tools you are less familiar with is
going to be a struggle.
Perhaps there is a more appropriate tool-chain and or library choice available for your needs
already. Then again maybe not given the rest of this thread. There is (someone will correct
me if I'm wrong) some consensus that gdc is the way to go on linux. Especially if you are
only intending to use D v1 and not v2 (in spite of all the extra coolness it makes available).

Regards,

Bruce.

Bill Lear wrote:

> Sean Kelly Wrote:
> [...]
>> I agree with your comment on tools and libraries in general, but D does
>> already have a solid
>> install/update/build tool in DSSS/rebuild.  With it, installing supported
>> packages is as simple as "dsss net install blah", which I believe is
>> roughly equivalent to ruby gems or whatever you
>> used there instead.  Regarding DB support, I think some branch of DDBI
>> may actually build with the current version of D, but you're right that
>> it doesn't receive a lot of attention. Unfortunately, D is still very
>> much a language for self-starters, and the overarching focus on newer and
>> more features rather than building a solid base for development probably
>> doesn't help things either.  Overall, the trend seems to be a churn of
>> new users rather than
>> a growing group of serious professionals--likely for these reasons.  That
>> said, there are more than a few professional developers which have found
>> a development environment which suits them--from my experience it tends
>> to be DMD/Linux and Tango with either makefiles or DSSS for building and
>> GDB with the demangling patch for debugging.
> 
> Thanks to all for the (mostly) thoughtful comments on this issue.  I have tried again, this time documenting my steps, to more thouroughly illustrate what I am going through.  Here is a more-or-less verbatim run of my efforts to get dbi compiled and installed.  To say the least, the results are less than satisfying: Download and install d 1.030.
> 
> Go to D web site to find OBI component.  Look for something that
> indicates "tools", or "libraries" for D.  See "Tools" section.
> Look in "More Tools" link.  Nothing there, so back to the
> main page.  Look under "Community"/"D links".  Looks good.
> Using Firebugs, search for "Database" on the page.  Find D DBI.
> Ok, click it.
> 
> Look for "downloads".  Find "Recommended" is "Version 0.2.5", so download that to my build directory and unzip the zip file.
> 
> Look for and find doc on "HowToBuild".  It says:
> 
> The current recommended way to build dbi.lib is to use buildme.d. It comes in the directory below dbi.
> 
> To build a release version of D DBI with every module, use any of the following:
> 
>     dmd -run buildme.d all
> 
> So, I try the first command:
> 
> % cd tags/0.2.5
> % dmd -run buildme.d all
> buildme.d: module buildme cannot read file 'buildme.d'
> 
> So, it fails because it cannot read the file.  So, I figure out why:
> 
> ls -l
> total 28
> ----------  1 rael rael 4478 2007-02-03 01:21 buildme.d
> drwxr-xr-x 10 rael rael 4096 2008-05-28 15:02 dbi drwxr-xr-x  3 rael rael 4096 2008-05-28 15:02 docs
> 
> It has unzipped things with no read permissions.  So, I fix it and try again:
> 
> % chmod +rw buildme.d
> % dmd -run buildme.d all
> buildme.d(42): module FileConst cannot read file 'tango/io/FileConst.d'
> 
> With no clue as to what this means, I read the source file buildme.d, and discover that it appears to support two versions, Phobos, and something else, presumably Tango.  So, I read the dmd doc to see how to set this flag (dmd -Dversion=Phobos didn't work).  Finding that, I try again, and fail again:
> 
> % dmd -version=Phobos -run buildme.d all
> sh: bud: command not found
> 
> So, I try to find bud.  I go back to the dlinks page and find it and download it, and attempt to build IT:
> 
> % cd bud-3.04
> 
> The instructions say:
> 
> If you have no existing binary, the executable must be built with the makefile first:
> 
> make -f Makefile.unix
> 
> So, I try that:
> 
> % make -f Makefile.unix
> make: Makefile.unix: No such file or directory
> make: *** No rule to make target `Makefile.unix'.  Stop.
> 
> Ah, ok.  Let's see what's wrong now:
> 
> % ls
> Source
> 
> Ok, would have been nice to document that, but forging ahead...
> 
> % cd Source
> % make -f Makefile.unix
> dmd -op -release -inline -ofbuild build.d util/pathex_bn.d util/pathex.d
> source_bn.d util/str.d build_bn.d util/booltype.d util/fdt_bn.d
> util/str_bn.d source.d util/fdt.d util/fileex.d util/fileex_bn.d
> util/linetoken.d util/linetoken_bn.d util/macro.d util/file2.d
> build.d(56): Identifier expected following package build.d(56): ';'
> expected build.d(634): identifier expected following '.', not 'macro'
> build.d(3348): identifier expected following '.', not 'macro'
> source.d(55): Identifier expected following package source.d(55): ';'
> expected source.d(105): Identifier expected following package
> source.d(105): ';' expected source.d(483): identifier expected following
> '.', not 'macro' util/macro.d(38): Identifier expected following package
> make: *** [build] Error 1
> 
> So, the build tool itself advertised to build the tool I want to use fails to build.  Irony...
> 
> So, I discover after a long set of searches and guess on my part that 'util.macro' should perhaps be 'util.Macro'.  I make those substitutions in the bud source code and the build of it finally works:
> 
> % make -f Makefile.unix
> dmd -op -release -inline -ofbuild build.d util/pathex_bn.d util/pathex.d
> source_bn.d util/str.d build_bn.d util/booltype.d util/fdt_bn.d
> util/str_bn.d source.d util/fdt.d util/fileex.d util/fileex_bn.d
> util/linetoken.d util/linetoken_bn.d util/macro.d util/file2.d
> 
> Noting that the bud build instructions also say:
> 
> It is still imperative to build a final binary with the utility itself:
> 
>     ./build build -full -op
>     ln -s build bud
> 
> So:
> 
> % ./build build -full -op
> Source.d(55): module Macro cannot read file 'util/Macro.d'
> 
> Of course not.  So, I move util/macro.d to util/Macro.d:
> 
> % mv util/macro.d util/Macro.d
> 
> try again:
> 
> % ./build build -full -op
> /usr/bin/ld: skipping incompatible /usr/lib/libphobos.a when searching for
> -lphobos /usr/bin/ld: cannot find -lphobos
> collect2: ld returned 1 exit status
> 
> Usure how a freshly installed libphobos.a from the freshly installed dmd package could be a problem:
> 
> % which dmd
> /opt/dmd/bin/dmd
> % ls -l /opt/dmd/lib/libphobos.a
> -rw-r--r-- 1 rael rael 1344630 2008-05-16 23:01 /opt/dmd/lib/libphobos.a
> % ls -l /usr/lib/libphobos.a
> -rw-r--r-- 1 root root 1344630 2008-05-28 14:17 /usr/lib/libphobos.a
> % cmp /opt/dmd/lib/libphobos.a /usr/lib/libphobos.a
> % echo $?
> 0
> 
> So, the files are identical...
> 
> Oh, and here's another cool thing:
> 
> % ls -l build
> ls: cannot access build: No such file or directory
> 
> So, the build failure erases the build file itself.  Very, very cool.
> 
> So, rebuild from makefile:
> 
> % make -f Makefile.unix
> make: *** No rule to make target `util/macro.d', needed by `build'.  Stop.
> 
> Of course.  So, I link util/Macro.d to util/macro.d:
> 
> % cd util/
> % ln -s Macro.d macro.d
> % cd ..
> % make -f Makefile.unix
> dmd -op -release -inline -ofbuild build.d util/pathex_bn.d util/pathex.d
> source_bn.d util/str.d build_bn.d util/booltype.d util/fdt_bn.d
> util/str_bn.d source.d util/fdt.d util/fileex.d util/fileex_bn.d
> util/linetoken.d util/linetoken_bn.d util/macro.d util/file2.d
> 
> And now, move build to something else, perhaps?:
> 
> % mv build buildit
> % ./buildit build -full -op
> /usr/bin/ld: skipping incompatible /usr/lib/libphobos.a when searching for
> -lphobos /usr/bin/ld: cannot find -lphobos
> collect2: ld returned 1 exit status
> 
> And now I discover that since I have a 64-bit machine, perhaps I am just totally hosed?
> 
> dmd itself seems to work fine:
> 
> % cd /opt/dmd/samples/d/
> % dmd wc.d
> % echo "Hello world" | ./wc
> % ./wc wc.d
>    lines   words   bytes file
>       45      80     810 wc.d
> 
> So, what the hell, I'll try with the version of bud built from the makefile and see if that is good enough:
> 
> % cp buildit ~/bin
> % cd /build/tags/0.25
> % dmd -version=Phobos -run buildme.d all
> Error: dbi/all.d: Permission denied
> 
> Lovely, more permissions errors:
> 
> % ls -l dbi/all.d
> ---------- 1 rael rael 250 2007-02-03 01:21 dbi/all.d
> 
> So, fix them:
> 
> % find . -type f | xargs chmod +rw
> 
> and try again:
> 
> %  dmd -version=Phobos -run buildme.d all
> dbi/oracle/imp/orl.d(1147): found 'ref' when expecting ')'
> dbi/oracle/imp/orl.d(1147): semicolon expected following function
> declaration dbi/oracle/imp/orl.d(1147): Declaration expected, not ')'
> dbi/oracle/imp/orl.d(1188): found 'ref' when expecting ')'
> dbi/oracle/imp/orl.d(1188): semicolon expected following function
> declaration dbi/oracle/imp/orl.d(1188): Declaration expected, not ')'
> dbi/oracle/imp/orl.d(1200): found 'ref' when expecting ')'
> dbi/oracle/imp/orl.d(1200): semicolon expected following function
> declaration dbi/oracle/imp/orl.d(1200): Declaration expected, not ')'
> dbi/oracle/imp/orl.d(1216): found 'ref' when expecting ')'
> dbi/oracle/imp/orl.d(1216): semicolon expected following function
> declaration dbi/oracle/imp/orl.d(1216): Declaration expected, not ')'
> dbi/oracle/imp/orl.d(1231): found 'ref' when expecting ')'
> dbi/oracle/imp/orl.d(1231): semicolon expected following function
> declaration dbi/oracle/imp/orl.d(1231): Declaration expected, not ','
> dbi/oracle/imp/ori.d(404): found 'ref' when expecting ')'
> dbi/oracle/imp/ori.d(404): semicolon expected following function
> declaration dbi/oracle/imp/ori.d(404): Declaration expected, not ')'
> dbi/oracle/imp/ori.d(1106): found 'ref' when expecting ')'
> dbi/oracle/imp/ori.d(1106): semicolon expected following function
> declaration dbi/oracle/imp/ori.d(1106): Declaration expected, not ')'
> 
> Ok, it's building oracle.  I don't really want oracle.  The code says I can pass '-mysql'.  Try that:
> 
> % dmd -version=Phobos -run buildme.d -mysql
> Error: Invalid argument "-mysql."  "mysql" isn't on the list of DBDs to
> build.
> 
> Try again:
> 
> % dmd -version=Phobos -run buildme.d mysql
> 
> Hmm, no errors, no nothing.  What did it do?
> 
> % ls -lt
> total 36
> drwxr-xr-x 10 rael rael 4096 2008-05-28 16:03 dbi
> drwxr-xr-x  2 rael rael 4096 2008-05-28 16:03 libddbi.a
> drwxr-xr-x  3 rael rael 4096 2008-05-28 15:52 docs
> -rw-r--r--  1 rael rael 4478 2007-02-03 01:21 buildme.d
> 
> % ls -l libddbi.a/
> total 0
> % ls -lt dbi/
> total 264
> -rw-r--r-- 1 rael rael 124890 2008-05-28 16:03 all.a
> drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 ib
> drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 msql
> drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 mssql
> drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 mysql
> drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 odbc
> drwxr-xr-x 3 rael rael   4096 2008-05-28 15:52 oracle
> drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 pg
> drwxr-xr-x 2 rael rael   4096 2008-05-28 15:52 sqlite
> -rw-r--r-- 1 rael rael    250 2007-02-03 01:21 all.d
> -rw-r--r-- 1 rael rael   5813 2007-02-03 01:21 Database.d
> -rw-r--r-- 1 rael rael   2658 2007-02-03 01:21 DBIException.d
> -rw-r--r-- 1 rael rael   2500 2007-02-03 01:21 ErrorCode.d
> -rw-r--r-- 1 rael rael   1192 2007-02-03 01:21 Result.d
> -rw-r--r-- 1 rael rael   4194 2007-02-03 01:21 Row.d
> -rw-r--r-- 1 rael rael   6736 2007-02-03 01:21 Statement.d
> 
> Hm, ok, we have an 'all.a' file and some .d files, so presumably
> we'll have to install these somewhere.  No clue if it actually
> built what I wanted ... There is no install
> target, it appears (thank goodness we're not using make!).  So, we
> look for example code on the web site:
> 
> Another recommended way to learn how to use D DBI is to look at the unittests in the SqliteDatabase file.
> 
> When I click on the link:
> 
> Internal Server Error
> 
> 500 Internal Server Error (No node /trunk/dbi/sqlite/sqlitedatabase.d at revision 91<br><p>You can <a
>
href="/projects/ddbi/log/trunk/dbi/sqlite/sqlitedatabase.d?rev=91&amp;mode=path_history">search</a>
> in the repository history to see if that path existed but was later removed.</p>)
> 
> Oops...
> 
> So, I try to run the unit test code.  Guessing:
> 
> % dmd -version=Phobos -run dbi/mysql/MysqlDatabase.d dbi/all.a
> -lmysqlclient
> [big fat failure]
> 
> Try again:
> 
> %  dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a -lmysqlclient Error: unrecognized switch '-lmysqlclient'
> 
> and again:
> 
> % dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a [... vast spewage ...]
> 
> Well, ok, try again:
> 
> % dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a -L'-L/usr/lib/mysql -lmysqlclient'
> 
> and more failures.
> 
> Try again:
> 
> % dmd -version=Phobos -unittest dbi/mysql/MysqlDatabase.d dbi/all.a /usr/lib/mysql/libmysqlclient.a
> 
> Well, it gets by the undefined references to mysql internals, but of course new undefined errors show up.
> 
> [More tail chasing elided here for sake of space.]
> 
> At this point, I've wasted, not "20 minutes" as claimed here, but a solid 2 1/2 hours of my time.
> 
> I do hope others realize that I have gone to the trouble to document this not to impugn anyone's motives, but to provide what I think is a valuable service to the D community, while at the same time declining to join said community due to professional and personal time constraints.
> 
> Perhaps I'll return to this effort tomorrow and see if I can kick it along any further, but I rather doubt I will, as even if I do get the thing to compile, my confidence in the entire body of code is so low that I am loathe to recommend that our development group even consider it for production-ready code.
> 
> Some observations:
> 
> 1) Using "yet another make system" to build dbi seems of dubious benefit.
> 
> 2) Even the most basic issues do not go well --- the source code wouldn't even unzip properly.
> 
> 3) If users are to adopt D, then the support universe around it needs to be strengthened.  Anything more than a few keystrokes' to install something is going to turn away potential legions of followers.  I'd like to see this:
> 
> % dinstall dbi
> DBI is now installed for D.  Have fun.
> 
> And I think that is a reasonable goal to aim for.
> 
> As I said, I just don't have the time presently to contribute any more than I have to this, and I hope this will help the D community in some way.
> 
> Thanks.
> 
> 
> Bill

Thank you - I will save this for later reference.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Bill Lear wrote:
> [...]

First I can say that there are two runtime libraries available, the standard library Phobos and the alternative community developed runtime library Tango.

The problems you have with bud is that it's code is very old and D has introduced new keywords (ref, macro) since then which conflicts with the module and variable names. If you want to build bud then you have to change all the module and variable names that conflicts with the new keywords, this includes both source files and make files. But I think you should use dsss (see below) instead.

dmd is not 64bit compatible so you have to use gdc or dmd with 32bit libraries.

> % dinstall dbi
> DBI is now installed for D.  Have fun.

This can be done with the dsss tool:
dsss net install ddbi

This will download, compile and install ddbi.

I think the best and easiest way to get D (and Tango) working is downloading a tango bundle (D compiler with the Tango runtime library pre-compiled) which exists for the platforms osx,linux and windows and then download dsss as a pre-compiled binary.

dmd bundled with Tango for windows and linux: http://www.dsource.org/projects/tango/wiki/DmdDownloads

gdc bundled with Tango for linux and osx:
http://www.dsource.org/projects/tango/wiki/GdcDownloads

pre-compiled dsss binary for linux, windows and osx:
http://svn.dsource.org/projects/dsss/downloads/0.75/

I completely agree with you that the lack of documentation is a big problem, I know that it was for me when I started, and I had big problems before I found the right tools to use.

BTW I think ddbi is going through some changes and I've seen that other people have problems with it.