www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd/druntime/phobos makefile horror

reply Trass3r <un known.com> writes:
I've always built my libs like that:

cd druntime
git pull -v
make MODEL=64 -f posix.mak -j2
make MODEL=32 -f posix.mak -j2

cd ../phobos
git pull -v
make MODEL=64 -f posix.mak -j2 && mv  
generated/linux/release/64/libphobos2.a ../../linux/lib64
make MODEL=32 -f posix.mak -j2 && mv  
generated/linux/release/32/libphobos2.a ../../linux/lib32


Normally I don't need 32bit but now I tried to build an app which fails  
miserably with phobos2 not found.
After removing -L--no-warn-search-mismatch and playing with 'ar x' and  
'file' I finally found out 32bit libphobos contains the 64bit version of  
druntime.
The reason is druntime doesn't build separate libs like phobos does.

This is just an example of the incoherence of the build system. (Another  
really bad one is dmd's makefile not allowing to specify debug/release  
while the windows version sort of does)
Can't we get this straight once and for all?
Dec 16 2011
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 16-12-2011 16:48, Trass3r wrote:

 I've always built my libs like that:

 cd druntime
 git pull -v
 make MODEL=64 -f posix.mak -j2
 make MODEL=32 -f posix.mak -j2

 cd ../phobos
 git pull -v
 make MODEL=64 -f posix.mak -j2 && mv
 generated/linux/release/64/libphobos2.a ../../linux/lib64
 make MODEL=32 -f posix.mak -j2 && mv
 generated/linux/release/32/libphobos2.a ../../linux/lib32


 Normally I don't need 32bit but now I tried to build an app which fails
 miserably with phobos2 not found.
 After removing -L--no-warn-search-mismatch and playing with 'ar x' and
 'file' I finally found out 32bit libphobos contains the 64bit version of
 druntime.


Ahahaha! So that explains those weird linker errors I never figured out!


 The reason is druntime doesn't build separate libs like phobos does.

 This is just an example of the incoherence of the build system. (Another
 really bad one is dmd's makefile not allowing to specify debug/release
 while the windows version sort of does)
 Can't we get this straight once and for all?


I still wonder why druntime has to be in libphobos. It seems silly and 
error-prone to me.

- Alex
Dec 16 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Also why does druntime come with .di headers but phobos does not? OTOH
I doubt it would save much on compilation time since virtually
everything in phobos is a template..
Dec 16 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, December 16, 2011 17:41:13 Andrej Mitrovic wrote:

 Also why does druntime come with .di headers but phobos does not? OTOH
 I doubt it would save much on compilation time since virtually
 everything in phobos is a template..


It would also kill CTFE for stuff that isn't a template. I'd sooner have 
druntime _not_ use .di files than have Phobos use them. However, I believe that 
one of the reasons that druntime does is so that compilation time is saved for 
the garbage collector.

- Jonathan M Davis
Dec 16 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 12/16/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 It would also kill CTFE for stuff that isn't a template.


I never thought of that.. interesting, so if you want to hide your
sources your users won't be able to use CTFE. (I don't mind that, idc
about any closed-source D /libraries/).
Dec 16 2011
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Dec 16, 2011, at 8:45 AM, Jonathan M Davis wrote:


 On Friday, December 16, 2011 17:41:13 Andrej Mitrovic wrote:

 Also why does druntime come with .di headers but phobos does not? =




OTOH

 I doubt it would save much on compilation time since virtually
 everything in phobos is a template..


=20
 It would also kill CTFE for stuff that isn't a template.


Yup.  I may have to change the build process to simply copy modules to =
the import directory so CTFE works.  It just stinks that this would be =
necessary.=
Dec 16 2011
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, December 16, 2011 18:45:01 Andrej Mitrovic wrote:

 On 12/16/11, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 It would also kill CTFE for stuff that isn't a template.


 
 I never thought of that.. interesting, so if you want to hide your
 sources your users won't be able to use CTFE. (I don't mind that, idc
 about any closed-source D /libraries/).


Templates need to be in the .di file regardless, but for anything not in the 
.di file, you can't inline it or use it in CTFE. As such, I'm generally very 
much against the use of .di files. We've actually had some issues with stuff
not 
being CTFEable because its source wasn't in druntime's .di files.

- Jonathan M Davis
Dec 16 2011
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 16-12-2011 19:27, Jonathan M Davis wrote:

 On Friday, December 16, 2011 18:45:01 Andrej Mitrovic wrote:

 On 12/16/11, Jonathan M Davis<jmdavisProg gmx.com>  wrote:

 It would also kill CTFE for stuff that isn't a template.


 I never thought of that.. interesting, so if you want to hide your
 sources your users won't be able to use CTFE. (I don't mind that, idc
 about any closed-source D /libraries/).


 Templates need to be in the .di file regardless, but for anything not in the
 .di file, you can't inline it or use it in CTFE. As such, I'm generally very
 much against the use of .di files. We've actually had some issues with stuff
not
 being CTFEable because its source wasn't in druntime's .di files.

 - Jonathan M Davis


That does seem like a major drawback for anything open source.

- Alex
Dec 16 2011
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, December 16, 2011 18:55:29 Alex Rønne Petersen wrote:

 On 16-12-2011 19:27, Jonathan M Davis wrote:

 On Friday, December 16, 2011 18:45:01 Andrej Mitrovic wrote:

 On 12/16/11, Jonathan M Davis<jmdavisProg gmx.com> wrote:

 It would also kill CTFE for stuff that isn't a template.


 
 I never thought of that.. interesting, so if you want to hide your
 sources your users won't be able to use CTFE. (I don't mind that, idc
 about any closed-source D /libraries/).


 
 Templates need to be in the .di file regardless, but for anything not in
 the .di file, you can't inline it or use it in CTFE. As such, I'm
 generally very much against the use of .di files. We've actually had
 some issues with stuff not being CTFEable because its source wasn't in
 druntime's .di files.
 
 - Jonathan M Davis


 
 That does seem like a major drawback for anything open source.


Why open source? I mean, if you want to use .di files, that's a problem in 
general, but what's worse about open source? Usually, I'd expect someone to 
say that it's worse for closed source, since it makes it harder to give the 
equivalent of a header file when dealing with 3rd parties you don't want to 
give all of your code to.

- Jonathan M Davis
Dec 16 2011
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 16 December 2011 at 15:48:50 UTC, Trass3r wrote:

 (Another really bad one is dmd's makefile not allowing to 
 specify debug/release while the windows version sort of does)


I wonder, would it be hard to write our own make implementation 
(in D) to replace the DigitalMars one? The goal would be to add 
support for all the GNU extensions that the posix makefiles use 
(and the win32 ones make up for with metric tons of copy-pasta), 
perhaps add built-ins for common POSIX commands, and unify the 
makefiles.
Dec 16 2011
parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Fri, 16 Dec 2011, Vladimir Panteleev wrote:


 On Friday, 16 December 2011 at 15:48:50 UTC, Trass3r wrote:

 (Another really bad one is dmd's makefile not allowing to specify
 debug/release while the windows version sort of does)


 
 I wonder, would it be hard to write our own make implementation (in D) to
 replace the DigitalMars one? The goal would be to add support for all the GNU
 extensions that the posix makefiles use (and the win32 ones make up for with
 metric tons of copy-pasta), perhaps add built-ins for common POSIX commands,
 and unify the makefiles.


It'd be a lot harder than just using gnumake which already does all that.  
Why invest all the time it'd take when a very workable solution already 
exists?
Dec 16 2011
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 16 December 2011 at 21:18:45 UTC, Brad Roberts wrote:

 On Fri, 16 Dec 2011, Vladimir Panteleev wrote:


 On Friday, 16 December 2011 at 15:48:50 UTC, Trass3r wrote:

 (Another really bad one is dmd's makefile not allowing to 
 specify
 debug/release while the windows version sort of does)


 
 I wonder, would it be hard to write our own make 
 implementation (in D) to
 replace the DigitalMars one? The goal would be to add support 
 for all the GNU
 extensions that the posix makefiles use (and the win32 ones 
 make up for with
 metric tons of copy-pasta), perhaps add built-ins for common 
 POSIX commands,
 and unify the makefiles.


 It'd be a lot harder than just using gnumake which already does 
 all that.  Why invest all the time it'd take when a very 
 workable solution already exists?


The answer to that question is the same one as why DMD on Windows 
doesn't use GNU make already. If the reason is significant (e.g. 
lots of dependencies, sub-par native Windows support, licensing), 
writing a make implementation doesn't seem too hard.
Dec 16 2011
prev sibling parent reply Trass3r <un known.com> writes:
 The reason is druntime doesn't build separate libs like phobos does.


A quick and dirty patch would be:

diff --git a/posix.mak b/posix.mak
index 5fd7fee..9ed2004 100644
--- a/posix.mak
+++ b/posix.mak
   -32,9 +32,9    UDFLAGS=-m$(MODEL) -O -release -nofloat -w -d -Isrc  
-Iimport -property

  CFLAGS=-m$(MODEL) -O

-OBJDIR=obj
+OBJDIR=obj/$(MODEL)
  DRUNTIME_BASE=druntime
-DRUNTIME=lib/lib$(DRUNTIME_BASE).a
+DRUNTIME=lib/$(MODEL)/lib$(DRUNTIME_BASE).a

  DOCFMT=
Dec 29 2011
parent "Christian Manning" <cmanning999 gmail.com> writes:
On Friday, 30 December 2011 at 00:34:13 UTC, Trass3r wrote:

 The reason is druntime doesn't build separate libs like phobos 
 does.


 A quick and dirty patch would be:

 diff --git a/posix.mak b/posix.mak
 index 5fd7fee..9ed2004 100644
 --- a/posix.mak
 +++ b/posix.mak
    -32,9 +32,9    UDFLAGS=-m$(MODEL) -O -release -nofloat -w -d 
 -Isrc -Iimport -property

 CFLAGS=-m$(MODEL) -O

 -OBJDIR=obj
 +OBJDIR=obj/$(MODEL)
 DRUNTIME_BASE=druntime
 -DRUNTIME=lib/lib$(DRUNTIME_BASE).a
 +DRUNTIME=lib/$(MODEL)/lib$(DRUNTIME_BASE).a

 DOCFMT=


I've been using a similar patch for a while, originally from 
https://bugs.gentoo.org/show_bug.cgi?id=355527 but less of those 
changes are needed now so it's been stripped down a lot. Would be 
nice to have this upstream so a proper multilib d toolchain can 
be built out of the box

--- a/src/druntime/posix.mak	2011-06-25 01:39:28.000000000 +0100
+++ b/src/druntime/posix.mak	2011-07-13 16:27:21.307999841 +0100
   -25,16 +25,16   
DOCDIR=doc
IMPDIR=import

-MODEL=32
+MODEL?=32

DFLAGS=-m$(MODEL) -O -release -inline -nofloat -w -d -Isrc 
-Iimport -property
UDFLAGS=-m$(MODEL) -O -release -nofloat -w -d -Isrc -Iimport 
-property

CFLAGS=-m$(MODEL) -O

-OBJDIR=obj
+OBJDIR=obj$(MODEL)
DRUNTIME_BASE=druntime
-DRUNTIME=lib/lib$(DRUNTIME_BASE).a
+DRUNTIME=lib$(MODEL)/lib$(DRUNTIME_BASE).a

DOCFMT=

--- a/src/phobos/posix.mak	2011-07-10 21:19:30.000000000 +0100
+++ b/src/phobos/posix.mak	2011-07-13 16:27:11.585999804 +0100
   -75,7 +75,7   


ifeq (,$(findstring win,$(OS)))
-	DRUNTIME = $(DRUNTIME_PATH)/lib/libdruntime.a
+	DRUNTIME = $(DRUNTIME_PATH)/lib$(MODEL)/libdruntime.a
else
	DRUNTIME = $(DRUNTIME_PATH)/lib/druntime.lib
endif
Dec 30 2011