On Wed, 13 Jun 2007 16:04:47 -0700, Kirk McDonald wrote:

> Chris Nicholson-Sauls wrote:
>> Daniel Keep wrote:
>> 
>>>> Just out of interest, do you have any pointers, on hand, as to why rebuild is better than bud? It does look like bud is not being developed but I have not had much experience with the tools yet.
>>>>
>>>> Thanks ahead,
>>>>
>>>> Myron.
>>>
>>>
>>> One reason why I've started moving over to rebuild is -oqPATH.  This tells rebuild to put the intermediate object files into the PATH directory with fully qualified names (aka: Gregorian Notation).
>>>
>>> The problem with bud is that, if I remember correctly, you either put the object files with the source files (which sticks them all over the bloody place), or all in one directory where you can get name clashes.
>>>
>>> That said, bud is slightly easier to use directly from the command line because you can have +targets.
>>>
>>>     -- Daniel
>> 
>> 
>> Actually (as I recall) you can avoid the clashes by passing bud both of -odPATH and --op (note double-dashes) which will recreate the packaging of modules as a directory tree rooted at PATH.  Not neccessarily as good as "Gregorian Notation" (which I still wish the compiler would adopt), but usable.
>> 
>> -- Chris Nicholson-Sauls
> 
> This breaks as soon as you specify any source files as their absolute path. (I forget all the details; it's been a while since I went and worked all this out.) If Bud is unable to determine a sensible relative path, it defaults to placing the object file alongside the source file.

No it doesn't. DMD does that, not Bud.

> (Which causes the usual litany of problems.)

What are these problems? I've not had them myself.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Derek Parnell wrote:
> On Wed, 13 Jun 2007 16:04:47 -0700, Kirk McDonald wrote:
> 
>> Chris Nicholson-Sauls wrote:
>>> Daniel Keep wrote:
>>>
>>>>> Just out of interest, do you have any pointers, on hand, as to why
>>>>> rebuild is better than bud? It does look like bud is not being developed
>>>>> but I have not had much experience with the tools yet.
>>>>>
>>>>> Thanks ahead,
>>>>>
>>>>> Myron.
>>>>
>>>> One reason why I've started moving over to rebuild is -oqPATH.  This
>>>> tells rebuild to put the intermediate object files into the PATH
>>>> directory with fully qualified names (aka: Gregorian Notation).
>>>>
>>>> The problem with bud is that, if I remember correctly, you either put
>>>> the object files with the source files (which sticks them all over the
>>>> bloody place), or all in one directory where you can get name clashes.
>>>>
>>>> That said, bud is slightly easier to use directly from the command line
>>>> because you can have +targets.
>>>>
>>>>     -- Daniel
>>>
>>> Actually (as I recall) you can avoid the clashes by passing bud both of -odPATH and --op (note double-dashes) which will recreate the packaging of modules as a directory tree rooted at PATH.  Not neccessarily as good as "Gregorian Notation" (which I still wish the compiler would adopt), but usable.
>>>
>>> -- Chris Nicholson-Sauls
>> This breaks as soon as you specify any source files as their absolute path. (I forget all the details; it's been a while since I went and worked all this out.) If Bud is unable to determine a sensible relative path, it defaults to placing the object file alongside the source file. 
> 
> No it doesn't. DMD does that, not Bud.
> 

Er, you're right, of course.

>> (Which causes the usual litany of problems.)
> 
> What are these problems? I've not had them myself.
> 

Primarily, this causes issues if the source files are located in directories to which the user does not have write access.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

Derek Parnell wrote:
> On Thu, 14 Jun 2007 00:39:19 +1000, Daniel Keep wrote:
> 
>>> Just out of interest, do you have any pointers, on hand, as to why
>>> rebuild is better than bud? It does look like bud is not being developed
>>> but I have not had much experience with the tools yet.
>>>
>>> Thanks ahead,
>>>
>>> Myron.
>> One reason why I've started moving over to rebuild is -oqPATH.  This
>> tells rebuild to put the intermediate object files into the PATH
>> directory with fully qualified names (aka: Gregorian Notation).
>>
>> The problem with bud is that, if I remember correctly, you either put
>> the object files with the source files (which sticks them all over the
>> bloody place), or all in one directory where you can get name clashes.
> 
> A side effect of doing the -oqPATH is that is causes multiple runs of DMD,
> because DMD only knows how to write object files out to either the source
> file location or the location named on the -od switch. To have object files
> each placed in a separate location other than the source location means one
> has to run DMD separately for each source file (or at least for each unique
> source location).
> 

This is not strictly true. If there aren't actually any name collisions, you can just run DMD once and then rename/move the resulting object files to whatever scheme you want. If there is a name collision, then you can just compile all of the modules which don't collide first, rename them, and then compile the colliding ones. If I'm not mistaken, this is how rebuild works. Therefore, rebuild usually just calls DMD once, or sometimes twice.

> I have yet to workout why placement of object files is of such a critical
> issue. An object file is an intermediate file. It is used to either create
> an executable or a library, and then discarded. On rare occasions is can be
> retained to inspect the output machine code of the compiler, but why worry
> about where it lives. It will be discarded eventually.
> 

It is highly desirable to be able to jam all of these temporary files into a specific, off-to-the-side place. I do not like cluttering my source tree with temporary files.

> In Bud, I've chosen to reduce the number of calls to DMD instead of
> concerning myself about where to place temporary files. However, if this is
> really an issue I can have Bud call DMD multiple times for you to place
> temporary files in the folder of your choice.
> 

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

On Wed, 13 Jun 2007 21:55:53 -0700, Kirk McDonald wrote:

> Derek Parnell wrote:
>>> (Which causes the usual litany of problems.)
>> 
>> What are these problems? I've not had them myself.
>> 
> 
> Primarily, this causes issues if the source files are located in directories to which the user does not have write access.

A very good point indeed. It is because I don't work in such an environment (with D) I haven't had these issues.

Of course, it would be better if the compiler did this rather than 3rd party tools, so we should be lobbying the C++ lads that influence Walter to get DMD improved. <G>

I'll start working on Bud to provide this capability. I don't have Rebuild so my implementation of the concept is likely to be different, but I hope still useful.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
14/06/2007 5:41:07 PM

On Wed, 13 Jun 2007 22:10:09 -0700, Kirk McDonald wrote:

> It is highly desirable to be able to jam all of these temporary files into a specific, off-to-the-side place. I do not like cluttering my source tree with temporary files.

I use the "-clean" switch to immediately remove them.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
14/06/2007 5:47:24 PM

Derek Parnell wrote:
> On Wed, 13 Jun 2007 22:10:09 -0700, Kirk McDonald wrote:
> 
>> It is highly desirable to be able to jam all of these temporary files into a specific, off-to-the-side place. I do not like cluttering my source tree with temporary files.
> 
> I use the "-clean" switch to immediately remove them.
> 

Derek,

Are you still developing Bud or do you consider Bud complete? I only ask because it has been 8 months since the last change.

Regards,

Myron.

On Thu, 14 Jun 2007 12:49:45 +0200, Myron Alexander wrote:

> Derek Parnell wrote:
>> On Wed, 13 Jun 2007 22:10:09 -0700, Kirk McDonald wrote:
>> 
>>> It is highly desirable to be able to jam all of these temporary files into a specific, off-to-the-side place. I do not like cluttering my source tree with temporary files.
>> 
>> I use the "-clean" switch to immediately remove them.
>> 
> 
> Derek,
> 
> Are you still developing Bud or do you consider Bud complete? I only ask because it has been 8 months since the last change.

I am still developing it. I have a number of changes already coded into it but nothing revolutionary. I'll add the facility to name the alternative output file location(s) and then release the next version.

I have been wondering about using some post V1.0 features but now I've decided not to do that yet. However, I've refactored a lot of the code to make the modules a lot more self-suffcient and reduce cohesion between them.


-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Derek Parnell wrote:
> I am still developing it. I have a number of changes already coded into it
> but nothing revolutionary. I'll add the facility to name the alternative
> output file location(s) and then release the next version.
> 
> I have been wondering about using some post V1.0 features but now I've
> decided not to do that yet. However, I've refactored a lot of the code to
> make the modules a lot more self-suffcient and reduce cohesion between
> them. 
> 
> 

That's good news.

Thanks.

Myron.