Lionello Lunesu wrote:
>> You can create a page by just typing in the URL in your browser, such as: http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/CompilePhobos
> 
> Done, and that exact spot!
> Still, it's a silly story. I mean, the biggest difficulty is the
> makefile. Building Phobos would be a no-brainer if the makefile would
> just build out of the box.
> 
> Walter, the missing files: are they obsolete, or just not included in the dmd distribution for license issues?
> 
> L.

There's always the third alternative: "oops; didn't notice they were missing" :)

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Lionello Lunesu wrote:

> Still, it's a silly story. I mean, the biggest difficulty is the makefile. Building Phobos would be a no-brainer if the makefile would just build out of the box.

Also, having a "make install" target would help with Linux packaging...

Currently it all have to be pieced together with cp and chmod, and then
copy all the Phobos import modules with something like a "double tar" :

    (cd dmd/src/phobos; find -name '*.d' | xargs tar c) | \
         (cd "$(DESTDIR)$(prefix)/lib/phobos"; tar xo)

All the needed commands should be in the previously offered Linux SRPMS.

--anders

Anders F Björklund wrote:
> Lionello Lunesu wrote:
> 
>> Still, it's a silly story. I mean, the biggest difficulty is the makefile. Building Phobos would be a no-brainer if the makefile would just build out of the box.
> 
> 
> Also, having a "make install" target would help with Linux packaging...
> 
> Currently it all have to be pieced together with cp and chmod, and then
> copy all the Phobos import modules with something like a "double tar" :
> 
>     (cd dmd/src/phobos; find -name '*.d' | xargs tar c) | \
>          (cd "$(DESTDIR)$(prefix)/lib/phobos"; tar xo)
> 
> All the needed commands should be in the previously offered Linux SRPMS.

What if a shell script for that was included right in the DMD.ZIP itself?

Georg Wrede wrote:

>> Also, having a "make install" target would help with Linux packaging...
> 
> What if a shell script for that was included right in the DMD.ZIP itself?

Make install basically runs a shell script, but that was the idea yes.

Usually you do something like:
./configure && make
sudo make install

--anders

Anders F Björklund wrote:
> Georg Wrede wrote:
> 
>>> Also, having a "make install" target would help with Linux packaging...
>>
>>
>> What if a shell script for that was included right in the DMD.ZIP itself?
> 
> 
> Make install basically runs a shell script, but that was the idea yes.
> 
> Usually you do something like:
> ./configure && make
> sudo make install

Exactly.

(My point being that Walter doesn't have the time to study shell scripts or makefiles, so a ready-made one should be given to him.)

Incidentally, should that script be in dmd/bin or dmd/src?
(My vote: src.)

Georg Wrede wrote:

> Exactly.
> 
> (My point being that Walter doesn't have the time to study shell scripts or makefiles, so a ready-made one should be given to him.)

There has been several written. But Walter doesn't like ready packages ?

Partly I can understand where he is coming from on that; if the user
unpacks and installs the software themselves, they know where it went
and that it isn't doing anything "extra" - like install malware etc...

It's just that it is a hassle to type those commands, and then amplified
when wanting to upgrade or uninstall ? Thus, I prefer using RPM instead.
I could duplicate all the steps that I used, but it's in the "dmd.spec"

Not everyone uses RPM, but it's easy to adapt to a .deb or .ebuild too ?

> Incidentally, should that script be in dmd/bin or dmd/src?
> (My vote: src.)

I think it should be something like "dmd/install.sh", in that case...
(since DMD doesn't come with the complete sources to "bin", in "src")

#!/bin/sh

install -d /usr/local/bin
install -p -m 0755 bin/dmd bin/obj2asm bin/dumpobj \
                  /usr/local/bin

install -d /usr/local/man/man1
install -p -m 0644 man/man1/dmd.1 man/man1/obj2asm.1 \
                   man/man1/dumpobj.1 /usr/local/man/man1

install -d /usr/local/lib
install -p -m 0644 lib/libphobos.a /usr/local/lib

install -d /usr/local/lib/phobos
(cd src/phobos; find -name '*.d' | xargs tar c) | \
                   (cd /usr/local/lib/phobos; tar xv)
cat > /etc/dmd.conf <<__EOF__
[Environment]
DFLAGS="-I/usr/local/lib/phobos"
__EOF__

Something to that effect. Would install DMD and Phobos to /usr/local ?
Where "/usr/local" should probably be written as "${DESTDIR}$prefix":

DESTDIR=
prefix=/usr/local

Or even use $(bindir) and $(libdir), and default those to use $(prefix)

bindir=$prefix/bin
libdir=$prefix/lib

Walter can use as much or as little of it as he wants, I'm doing GDC....
(no use in doing more packages for DMD, since they can't be distributed)

--anders

I can only speak in my name - I will not use any "standard" D library other than Phobos, and my own libraries. Phobos is open-source, Mr. Bright is very much open person, and he will incorporate any sane change into Phobos.

Kind regards

Dejan Lekic

Dejan Lekic schrieb:
> Phobos is open-source, Mr. Bright is
> very much open person, and he will incorporate any sane change into Phobos.

Yes.

One good argument for java is its great library, which is allways available, in every installation. A library dealing also with encodings, file systems, xml parsing, template containers, synchronization classes, logging and so on can only be an advantage.

Perhaps, with giving away some responsibility, Walter can get more time for working on dmd 1.0

Dejan Lekic wrote:
> I can only speak in my name - I will not use any "standard" D library other than Phobos, and my own libraries. Phobos is open-source, Mr. Bright is very much open person, and he will incorporate any sane change into Phobos.

I'm going to have to disagree with you here.  Not on your choice of lib, but on Walter's commitment to Phobos.  He has repeatedly said that his focus is on the language spec and the DMD reference compiler, and always seeks contributions / prods the guys who are active for the library content.  So, while the D Language shines and the spec is solving all the C++ issues as noted in another recent post, Phobos, well, is part of D's overall lack-of-libraries issue.  It is interesting to note how good Phobos is, given its place in W's priority list - probably just another testament to his skill.

Scaling D, however, will take more than just Walter, and I don't think I'd get a lot of disagreement.  There are insane amounts of great code in Ares and Mango which go largely unused because we haven't had the stampede yet.  These libs speak to the skill of Sean & Kris, and all the testers/documenters they've had hanging around their libs.  The fact that they're actively developing those libs should be encouraging to all of us, as the chief complaint I hear in the NG is lack of libs.

Surely Walter doing compiler/spec things and Sean/Kris doing lib dev, Derek cranking out a new Build, {insert name here} working on a new version of {insert project here} is better than a one-man show?  And if a new lib ever comes around that is better/more complete than Phobos, won't you be compelled to take it for a spin?

BA

Brad Anderson wrote:
> Dejan Lekic wrote:
>> I can only speak in my name - I will not use any "standard" D library other
>> than Phobos, and my own libraries. Phobos is open-source, Mr. Bright is
>> very much open person, and he will incorporate any sane change into Phobos.
> 
> I'm going to have to disagree with you here.  Not on your choice of lib, but
> on Walter's commitment to Phobos.  He has repeatedly said that his focus is on
> the language spec and the DMD reference compiler, and always seeks
> contributions / prods the guys who are active for the library content.  So,
> while the D Language shines and the spec is solving all the C++ issues as
> noted in another recent post, Phobos, well, is part of D's overall
> lack-of-libraries issue.  It is interesting to note how good Phobos is, given
> its place in W's priority list - probably just another testament to his skill.
> 
> Scaling D, however, will take more than just Walter, and I don't think I'd get
> a lot of disagreement.  There are insane amounts of great code in Ares and
> Mango which go largely unused because we haven't had the stampede yet.  These
> libs speak to the skill of Sean & Kris, and all the testers/documenters
> they've had hanging around their libs.  The fact that they're actively
> developing those libs should be encouraging to all of us, as the chief
> complaint I hear in the NG is lack of libs.
> 
> Surely Walter doing compiler/spec things and Sean/Kris doing lib dev, Derek
> cranking out a new Build, {insert name here} working on a new version of
> {insert project here} is better than a one-man show?  And if a new lib ever
> comes around that is better/more complete than Phobos, won't you be compelled
> to take it for a spin?
> 
> BA


Well said!

-JJR