February 11, 2005
Dear DigitalMars and United Unix,

Should we bother for Makefiles even on D?
The Makefile-related autotool programs are obsolete because of:

(a) wasting time and cost in heavy environment inspections and expensive dynamic
data genarations
(b) these cheap-looked user-interfaces
(c) these non-portable procedure-oriented data format that depends on uncommon
options of individual tools

Thanks,


February 11, 2005
New Ape wrote:
> Dear DigitalMars and United Unix,
> 
> Should we bother for Makefiles even on D?
> The Makefile-related autotool programs are obsolete because of:
> 
> (a) wasting time and cost in heavy environment inspections and expensive dynamic
> data genarations
> (b) these cheap-looked user-interfaces
> (c) these non-portable procedure-oriented data format that depends on uncommon
> options of individual tools
> 
> Thanks,
> 
> 

Agreed. the makefile must die for D.   :-)
February 11, 2005
John Reimer wrote:
> New Ape wrote:
> 
>> Dear DigitalMars and United Unix,
>>
>> Should we bother for Makefiles even on D?
>> The Makefile-related autotool programs are obsolete because of:
>>
>> (a) wasting time and cost in heavy environment inspections and expensive dynamic
>> data genarations
>> (b) these cheap-looked user-interfaces
>> (c) these non-portable procedure-oriented data format that depends on uncommon
>> options of individual tools
>>
>> Thanks,
>>
>>
> 
> Agreed. the makefile must die for D.   :-)

Would dmake be the replacement?
February 11, 2005
clayasaurus wrote:
> John Reimer wrote:
> 
>> New Ape wrote:
>>
>>> Dear DigitalMars and United Unix,
>>>
>>> Should we bother for Makefiles even on D?
>>> The Makefile-related autotool programs are obsolete because of:
>>>
>>> (a) wasting time and cost in heavy environment inspections and expensive dynamic
>>> data genarations
>>> (b) these cheap-looked user-interfaces
>>> (c) these non-portable procedure-oriented data format that depends on uncommon
>>> options of individual tools
>>>
>>> Thanks,
>>>
>>>
>>
>> Agreed. the makefile must die for D.   :-)
> 
> 
> Would dmake be the replacement?

dmake or digc.  Both need improvement before they can qualify (but they're close!).

- John R.
February 11, 2005
In article <cugtuh$avd$1@digitaldaemon.com>, John Reimer says...
>
>New Ape wrote:
>> Dear DigitalMars and United Unix,
>> 
>> Should we bother for Makefiles even on D?
>> The Makefile-related autotool programs are obsolete because of:
>> 
>> (a) wasting time and cost in heavy environment inspections and expensive dynamic
>> data genarations
>> (b) these cheap-looked user-interfaces
>> (c) these non-portable procedure-oriented data format that depends on uncommon
>> options of individual tools
>> 
>> Thanks,
>> 
>> 
>
>Agreed. the makefile must die for D.   :-)

Thank god someone started this thread.

I can contribute dbuild, as it works to that end.  However, it's still mostly broken and badly in need of improvment.

DMake and Digc have also been suggested... perhaps we can all work toward a common protocol for tackling this problem?

I'd like to see something open-ended enough to incorporate something like ddoc and other bits into the toolchain (like DMC for building C libs) without approaching Make's complexity (and hassle).  Even if it means making a more complicated tool, I think it will be worth it in the end.

- EricAnderton at yahoo
February 11, 2005
On Fri, 11 Feb 2005 00:14:10 +0000 (UTC), New Ape wrote:

> Dear DigitalMars and United Unix,
> 
> Should we bother for Makefiles even on D?
> The Makefile-related autotool programs are obsolete because of:
> 
> (a) wasting time and cost in heavy environment inspections and expensive dynamic
> data genarations
> (b) these cheap-looked user-interfaces
> (c) these non-portable procedure-oriented data format that depends on uncommon
> options of individual tools
> 
> Thanks,

I am just about to release v1.0 of my Build utility. This has been based on the dmake program, but with lots of changes.

I'm currently updating the documentation for it, and it all should be ready for review in about 24 hours.

Currently, it can create an executable or a library (or neither) by just supplying it with the top level source code file name. It works out the dependencies and which files need compiling. It has support for identifying which libraries (if any) are needed by the linker by placing pragma statements in your source code ...

version(build) pragma(link, MySuperLibrary);

Once this version is out, I'll try to add DLL building support, and library maintenance (as opposed to creation) to the next version.

-- 
Derek
Melbourne, Australia
11/02/2005 2:57:06 PM
February 11, 2005
Derek Parnell wrote:

> I am just about to release v1.0 of my Build utility. This has been based on
> the dmake program, but with lots of changes.
> 
> I'm currently updating the documentation for it, and it all should be ready
> for review in about 24 hours.
> 
> Currently, it can create an executable or a library (or neither) by just
> supplying it with the top level source code file name. It works out the
> dependencies and which files need compiling. It has support for identifying
> which libraries (if any) are needed by the linker by placing pragma
> statements in your source code ...
> 
> version(build) pragma(link, MySuperLibrary);
> 
> Once this version is out, I'll try to add DLL building support, and library
> maintenance (as opposed to creation) to the next version.
> 

I was hoping you would post about your build utility. :-)

Between "build" and "dbuild" by pragma, I think some super-tool can be worked out.  A bunch of us should review these tools, fine tune some features, and discuss what further features should be supplied.

Specifically a project needs to be started on dsource.org to get the ball rolling.  Prior projects have been "proprietary", hidden away as special tools attatched to certain projects.  We need get a build tool project out in the open.

A few things we should be looking for in d build:

1) Support for dmd and gdc
2) Support for a minimum of Win32, Linux, and Darwin
3) Lib creation on all platforms
4) Consider dynamic library support on all platforms (sadly dmd can't do dlls for anything but win32 at present)
5) Stripping support built in for commercial projects (ala digc)

I'm sure there's plenty more ideas to work out.  We should be able to pull several techniques from different projects and combine them into one.

This is a start.

Later,

John
February 11, 2005
pragma wrote:
> 
> Thank god someone started this thread.
> 
> I can contribute dbuild, as it works to that end.  However, it's still mostly
> broken and badly in need of improvment.
> 
> DMake and Digc have also been suggested... perhaps we can all work toward a
> common protocol for tackling this problem?
> 
> I'd like to see something open-ended enough to incorporate something like ddoc
> and other bits into the toolchain (like DMC for building C libs) without
> approaching Make's complexity (and hassle).  Even if it means making a more
> complicated tool, I think it will be worth it in the end.
> 
> - EricAnderton at yahoo


I agree! It's about time this topic was discussed in earnest.  I remember you mentioning that you made a slew of changes for dbuild, although I never really looked into what you had done.

You're right.  We should pull Derek's build, Helmet's dmake, Burton's digc, and your dbuild all together and see what explosive concoction can be wrought.

I think we should get a dsource.org project set up soon.

Later,

John R.
February 11, 2005
John Reimer wrote:

>>>> The Makefile-related autotool programs are obsolete because of:
>>>
>>> Agreed. the makefile must die for D.   :-)
>>
>> Would dmake be the replacement?
> 
> dmake or digc.  Both need improvement before they can qualify (but they're close!).

Outside D world, dmake means "Distributed Make"

Code might be good, but name needs to change...

http://www.prowiki.org/wiki4d/wiki.cgi?Dmake

--anders
February 11, 2005
New Ape wrote:

> The Makefile-related autotool programs are obsolete because of:
> 
> (a) wasting time and cost in heavy environment inspections and expensive dynamic
> data genarations
> (b) these cheap-looked user-interfaces
> (c) these non-portable procedure-oriented data format that depends on uncommon
> options of individual tools

<rant>
Of course we need another Make tool! And another system language but C, and another version control system but CVS. The old ones are just sooo last century. Let's design and write and debug one each, from scratch...
</rant>

But if it means we can escape the current custom ones:
win32.mak, linux.mak, darwin.mak, (etc. etc. etc.)
Then I most certainly won't be just another nay-sayer...

Just as long as it avoids XML (ant) and Python (scons), I'm OK. :-)

--anders
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home