Chris Nicholson-Sauls wrote:
> BCS wrote:
> 
>>
>> I have some builds that have more non-D than D parts.
> 
> Depending on the details, you should be fine with BRF (Build Response File) and properly set up RDF (Rules Definition File) entry for the non-D parts.
> 
>> I have some builds that need the same file to be compiled several times under different version settings.
> 
> Now that's a tough one.  Could use a batch to explicitly compile that module a few times, with the different settings, followed by an invocation to build, and include in your BRF a directive to ignore that module.  Still a little much though.
> 
> 
> -- Chris Nicholson-Sauls

Build is good for what it does, mostly D projects that might have a few non D parts. But it seems a bit clumsy when things start getting more complicated.

I just had a neat thought, build figures out all of the dependencies of a build, could it be made to generate a makefile that will have the same effect?

</input>
<code file="foo.d">
import bar;
</code>

<code file="bar.d">
import baz;
</code>

<code file="baz.d">
...
</code>
</input>

<output>
foo	: foo.o bar.o baz.o
	dmd foo.o bar.o baz.o $(D_LINK)

foo.o	: foo.d bar.d baz.d
	dmd -c foo.d

bar.o	: bar.d baz.d
	dmd -c bar.d

baz.o	: baz.d
	dmd -c baz.d
</output>

On Mon, 24 Jul 2006 09:44:50 -0500, BCS wrote:

> Chris Nicholson-Sauls wrote:
>> BCS wrote:
>> 
>>>
>>> I have some builds that have more non-D than D parts.
>> 
>> Depending on the details, you should be fine with BRF (Build Response File) and properly set up RDF (Rules Definition File) entry for the non-D parts.
>> 
>>> I have some builds that need the same file to be compiled several times under different version settings.
>> 
>> Now that's a tough one.  Could use a batch to explicitly compile that module a few times, with the different settings, followed by an invocation to build, and include in your BRF a directive to ignore that module.  Still a little much though.
>> 
>> -- Chris Nicholson-Sauls
> 
> Build is good for what it does, mostly D projects that might have a few non D parts. But it seems a bit clumsy when things start getting more complicated.

Agreed. However, I would like to hear from people about the "more complicated" builds so that maybe I can do something about them. Personally, I try to avoid complications of this sort ;-)

I'm currently looking at the "multiple compile" idea in which a source can be made to under go mutliple compiles with different switch/options each time.

> I just had a neat thought, build figures out all of the dependencies of a build, could it be made to generate a makefile that will have the same effect?

Yes it could, but why?

It already creates a kind of makefile - the response files for the compiler and linker.

-- 
Derek Parnell

Derek wrote:
> On Mon, 24 Jul 2006 09:44:50 -0500, BCS wrote:
> 
>>
>>Build is good for what it does, mostly D projects that might have a few non D parts. But it seems a bit clumsy when things start getting more complicated.
> 
> 
> Agreed. However, I would like to hear from people about the "more
> complicated" builds so that maybe I can do something about them.
> Personally, I try to avoid complications of this sort ;-)
> 

Some of my more complicate builds have involved things like using Enki to generate d code compiling that into a program that then generates more d code and them compiling that. For example look at my NetIDL source, I have a makefile file that will start with only the hand generate files and build everything right on out through the examples. I use a hacked version of Enki so I have considered even putting it's bootstrap and build into the makefile.

Other things I have done include a sort of poor mans version control (copy everything needed into a new directory) which is pure shell scripting.

Some other makefiles use the generated executable to do things (like in the first case, but not code generation).

> I'm currently looking at the "multiple compile" idea in which a source can
> be made to under go mutliple compiles with different switch/options each
> time.
> 
> 
>>I just had a neat thought, build figures out all of the dependencies of a build, could it be made to generate a makefile that will have the same effect?
> 
> 
> Yes it could, but why? 

Have Build generate this make file, run it through something like sed to apply arbitrary modifications and then make the result. This would gain many of the benefits of build (automatic dependency searching) while being flexible enough to be used where build would be at its worst (lots of non D stuff)
I haven't spent much time looking at Build so It might already do what I want.

BCS wrote:
> Bruno Medeiros wrote:
>> BCS wrote:
>>
>>> Hasan Aljudy wrote:
>>>
>>>>
>>>> I think his point was, build shouldn't have been needed in the first place, because the functionality should've been a part of dmd.
>>>
>>>
>>> If it was there, my immediate first question would be "How do I turn it off?" and my next question would be (several months later) "DMD does that?". (repeat question 1)
>>
>>
>> Why is that, why wouldn't you use build's functionality?
>>
> 
> I like to be able to control things my self. I have some builds that have more non-D than D parts. I have some builds that need the same file to be compiled several times under different version settings. DMD couldn't do much of what I need without becoming more of a build tool than a compiler. Once I need to use something other than DMD (as it is now) to do the build, I want something more general purpose that DMD should ever become.

The functionality that I think should be part of DMD is the one that (just as javac) figures out the dependencies between modules and (optionally) compiles the whole dependencies together, or does some other work with the found dependencies. I think that it should be part because this is a language-dependent functionality, it requires knowledge of the language and partial parsing of the language source files (which is what the compiler already does and knows).
All other kinds of functionality, i.e., language-independent, should be handled by generic build tools (shell scripts, Make, Ant, SConS, etc.).

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D