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 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? =


 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.

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 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 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 =?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
prev sibling next sibling 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 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
prev sibling next sibling 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 # Set DRUNTIME name and full path 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