I'm rewriting the Linux makefile. The existing one works well and is small, but Walter complained about it being impenetrable and I agree. It uses weird string expansions and stuff.

Back when I wrote it that was the only method I could find to avoid repeating a lot of stuff for all OSs, builds, unittests, etc. Recently, inspired by Walter, I decided to go with a different approach that relies on recursive make invocations. That simplifies matters drastically: no more string expansions, no more '$$', no more crap.

By this I'm asking you what you'd like to see in the makefile. What are the builds that you need and use, and what builds you'd like to use that aren't there?


Andrei

I basically flunked the build processes course and I don't actually know Make.  My success rate compiling software on Linux is well under 50%.  I loved the old make file because it required no configuration, etc. and everything always worked.  My biggest concern is that, for new school programmers that don't use makefiles in their own projects and don't know how to fix them if something goes wrong, the build process needs to Just Work (TM) without any tweaking.  I frankly don't care how messy it is under the hood.

On Thu, Feb 18, 2010 at 10:26 AM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> I'm rewriting the Linux makefile. The existing one works well and is small, but Walter complained about it being impenetrable and I agree. It uses weird string expansions and stuff.
>
> Back when I wrote it that was the only method I could find to avoid repeating a lot of stuff for all OSs, builds, unittests, etc. Recently, inspired by Walter, I decided to go with a different approach that relies on recursive make invocations. That simplifies matters drastically: no more string expansions, no more '$$', no more crap.
>
> By this I'm asking you what you'd like to see in the makefile. What are the builds that you need and use, and what builds you'd like to use that aren't there?
>
>
> Andrei
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100218/92dbae6e/attachment.htm>

Andrei Alexandrescu wrote:
> I'm rewriting the Linux makefile. The existing one works well and is small, but Walter complained about it being impenetrable and I agree. It uses weird string expansions and stuff.
>
> Back when I wrote it that was the only method I could find to avoid repeating a lot of stuff for all OSs, builds, unittests, etc. Recently, inspired by Walter, I decided to go with a different approach that relies on recursive make invocations. That simplifies matters drastically: no more string expansions, no more '$$', no more crap.
>
> By this I'm asking you what you'd like to see in the makefile. What are the builds that you need and use, and what builds you'd like to use that aren't there?
>

make clean => removes all targets built by the makefile
make zip => creates a zip file of all the sources (not targets) referred
to by the makefile, including the makefile
make release => makes release build of the library (this is also the
default target)
make doc => makes html documentation
make debug => makes debug build of the library
make unittest => builds all unittests, runs them, deletes all built
unittest files upon successful completion
make install => copies library to /usr/lib

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100218/c5ddb609/attachment.htm>

On Feb 18, 2010, at 11:33 AM, Walter Bright wrote:
> 
> David Simcha wrote:
>> I basically flunked the build processes course and I don't actually know Make.  My success rate compiling software on Linux is well under 50%.  I loved the old make file because it required no configuration, etc. and everything always worked.  My biggest concern is that, for new school programmers that don't use makefiles in their own projects and don't know how to fix them if something goes wrong, the build process needs to Just Work (TM) without any tweaking.  I frankly don't care how messy it is under the hood.
> 
> I agree with everything you say, except the last sentence.

Same.  I'd rather have something easily maintainable but verbose vs. something terse and impenetrable.  The problem with the old old makefile is that any change had to be done in 3 places.  I just couldn't make sense of the new one.

Sean Kelly wrote:
> On Feb 18, 2010, at 11:33 AM, Walter Bright wrote:
>> David Simcha wrote:
>>> I basically flunked the build processes course and I don't actually know Make.  My success rate compiling software on Linux is well under 50%.  I loved the old make file because it required no configuration, etc. and everything always worked.  My biggest concern is that, for new school programmers that don't use makefiles in their own projects and don't know how to fix them if something goes wrong, the build process needs to Just Work (TM) without any tweaking.  I frankly don't care how messy it is under the hood.
>> I agree with everything you say, except the last sentence.
> 
> Same.  I'd rather have something easily maintainable but verbose vs. something terse and impenetrable.  The problem with the old old makefile is that any change had to be done in 3 places.  I just couldn't make sense of the new one.

Agreed. The new makefile (written by me) passes perfectly at Don't Repeat Yourself and can do quite a lot of stuff, but has become very difficult to look at.

But some pain is gain. That experience led to a better makefile that I will finalize soon. That is at the same time easy to understand and non-redundant.


Andrei

I finally found time to rewrite the makefile. It's now short, sweet and easy to look at and modify.

The key is to use recursive invocations of make, each focused on one build (a given OS and a given flavor). That way dependencies are easy to set up without duplication. It took me a while to figure out how to do that stuff... the result is quite simple.

I actually copied Walter's description below as the documentation. The only differences are that I changed "doc" to "html" because some day we might have other doc formats, and also that I do not remove the successful unittests. This is because I don't want two successive invocations of make unittest to redo all successful unittests before it stops at the failing one.

I've only tested the Linux build, but I'm confident that the others need only minor adjustments, and most importantly that it's not difficult to figure how to make those adjustments. Let me know!


Andrei

On 02/18/2010 01:32 PM, Walter Bright wrote:
> make clean => removes all targets built by the makefile
> make zip => creates a zip file of all the sources (not targets) referred
> to by the makefile, including the makefile
> make release => makes release build of the library (this is also the
> default target)
> make doc => makes html documentation
> make debug => makes debug build of the library
> make unittest => builds all unittests, runs them, deletes all built
> unittest files upon successful completion
> make install => copies library to /usr/lib
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: linux.mak
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100321/0d9936c7/attachment.ksh>

I am experiencing some problems with the new makefile.


Firstly, the location of libdruntime.a is specified as

     DRUNTIME = $(DRUNTIME_PATH)/lib/libdruntime.a

while I believe it should be

     DRUNTIME = $(DRUNTIME_PATH)/libdruntime.a

Secondly, when I just enter 'make', DMD complains that it can't find object.d.  I have to run

     make -f GNUmakefile OS=posix BUILD=debug DFLAGS=-I../druntime/import

to make it work.  It seems DMD isn't receiving the druntime imports directory by default.


-Lars


Andrei Alexandrescu wrote:
> I finally found time to rewrite the makefile. It's now short, sweet and easy to look at and modify.
> 
> The key is to use recursive invocations of make, each focused on one build (a given OS and a given flavor). That way dependencies are easy to set up without duplication. It took me a while to figure out how to do that stuff... the result is quite simple.
> 
> I actually copied Walter's description below as the documentation. The only differences are that I changed "doc" to "html" because some day we might have other doc formats, and also that I do not remove the successful unittests. This is because I don't want two successive invocations of make unittest to redo all successful unittests before it stops at the failing one.
> 
> I've only tested the Linux build, but I'm confident that the others need only minor adjustments, and most importantly that it's not difficult to figure how to make those adjustments. Let me know!
> 
> 
> Andrei
> 
> On 02/18/2010 01:32 PM, Walter Bright wrote:
>> make clean => removes all targets built by the makefile
>> make zip => creates a zip file of all the sources (not targets) referred
>> to by the makefile, including the makefile
>> make release => makes release build of the library (this is also the
>> default target)
>> make doc => makes html documentation
>> make debug => makes debug build of the library
>> make unittest => builds all unittests, runs them, deletes all built
>> unittest files upon successful completion
>> make install => copies library to /usr/lib
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On 18 February 2010 20:32, Walter Bright <walter at digitalmars.com> wrote:
>
>
> Andrei Alexandrescu wrote:
>>
>> I'm rewriting the Linux makefile. The existing one works well and is small, but Walter complained about it being impenetrable and I agree. It uses weird string expansions and stuff.
>>
>> Back when I wrote it that was the only method I could find to avoid repeating a lot of stuff for all OSs, builds, unittests, etc. Recently, inspired by Walter, I decided to go with a different approach that relies on recursive make invocations. That simplifies matters drastically: no more string expansions, no more '$$', no more crap.
>>
>> By this I'm asking you what you'd like to see in the makefile. What are the builds that you need and use, and what builds you'd like to use that aren't there?
>>
>
> make clean => removes all targets built by the makefile
> make zip => creates a zip file of all the sources (not targets) referred to
> by the makefile, including the makefile
> make release => makes release build of the library (this is also the default
> target)
> make doc => makes html documentation
> make debug => makes debug build of the library
> make unittest => builds all unittests, runs them, deletes all built unittest
> files upon successful completion
> make install => copies library to /usr/lib

Something I've just noticed:   druntime uses "make doc" to make the
docs, while phobos uses "make html".
We should use the same build name for both. Probably druntime should change.

Also doc building doesn't work out of the box on Windows.
I fixed this by adding these lines to the top of Phobos win32.mak:
DOCSRC = ../docsrc
STDDOC = $(DOCSRC)/std.ddoc

and replacing std.ddoc by $(STDDOC) elsewhere.

Great. Could you please commit?

Andrei

On 03/23/2010 10:23 PM, Don Clugston wrote:
> On 18 February 2010 20:32, Walter Bright<walter at digitalmars.com>  wrote:
>>
>>
>> Andrei Alexandrescu wrote:
>>>
>>> I'm rewriting the Linux makefile. The existing one works well and is small, but Walter complained about it being impenetrable and I agree. It uses weird string expansions and stuff.
>>>
>>> Back when I wrote it that was the only method I could find to avoid repeating a lot of stuff for all OSs, builds, unittests, etc. Recently, inspired by Walter, I decided to go with a different approach that relies on recursive make invocations. That simplifies matters drastically: no more string expansions, no more '$$', no more crap.
>>>
>>> By this I'm asking you what you'd like to see in the makefile. What are the builds that you need and use, and what builds you'd like to use that aren't there?
>>>
>>
>> make clean =>  removes all targets built by the makefile
>> make zip =>  creates a zip file of all the sources (not targets) referred to
>> by the makefile, including the makefile
>> make release =>  makes release build of the library (this is also the default
>> target)
>> make doc =>  makes html documentation
>> make debug =>  makes debug build of the library
>> make unittest =>  builds all unittests, runs them, deletes all built unittest
>> files upon successful completion
>> make install =>  copies library to /usr/lib
>
> Something I've just noticed:   druntime uses "make doc" to make the
> docs, while phobos uses "make html".
> We should use the same build name for both. Probably druntime should change.
>
> Also doc building doesn't work out of the box on Windows.
> I fixed this by adding these lines to the top of Phobos win32.mak:
> DOCSRC = ../docsrc
> STDDOC = $(DOCSRC)/std.ddoc
>
> and replacing std.ddoc by $(STDDOC) elsewhere.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos