"Derek Parnell" <derek@psych.ward> wrote in message news:vykv3a1dxxj4.c7i7sb0tgwzf$.dlg@40tude.net...
> On Mon, 14 Feb 2005 15:37:09 -0500, Nick Sabalausky wrote:
>
>> Nevermind that question. I just noticed that you give it the sourcefile
>> to
>> start with, and it finds the sources through the import statements. I has
>> assumed before that it just compiled all the sources in the directory.
>
> No problems.
>> I did find one bug though.  It hangs when it finds /+ +/ style comments
>> in a
>> source.
>
> Fixed this. It only happened if there were other styled comments within
> the
> /+ +/ pairs.
>
>   http://www.users.bigpond.com/ddparnell/build.zip
>
> The Docs are also include now. Click on INDEX.HTM to see them.
>
> -- 
> Derek
> Melbourne, Australia
> 15/02/2005 1:05:46 PM

It also happened anytime there was a foreward-slash inside the /+ +/ pair. Maybe it thought the slash was the start of a comment? But in any case, the new version works fine for me too.

"Derek Parnell" <derek@psych.ward> wrote in message news:1fqqbs4msc534$.10iv0xee627g4$.dlg@40tude.net...
> On Mon, 14 Feb 2005 15:02:26 -0500, Nick Sabalausky wrote:
>
>> If it finds more than one file with a main() or WinMain(), is it smart
>> enough to determine that two separate apps need to be built, and that the
>> two files with main() should not be linked together?
>>
>
> No it can't do that, but its a good idea. I'll add that to the product enhancement list. Also, I'll add a way to 'build' a directory so you don't really have to supply any file name on the command line if you don't need to.
>
> -- 
> Derek
> Melbourne, Australia
> 15/02/2005 1:03:52 PM

Awesome :).  I have to say, I'm really impressed with this app. It's sooo nice to not have to bother with any type of makefile. Heheh, I've been changing build tools like crazy lately. Just in the last month alone I've moved from NMake -> SCons -> A-A-P -> build ;)

Derek wrote:

> The source code is now available for the build utility I've been working on.
> 
>   http://www.users.bigpond.com/ddparnell/build.zip
> 
> This contains a number of source files, a Windows executable (build.exe), and some files to recompile the application.
> 
> First, extract all the files from the zip into a single directory.

This directory should be a part of the zipfile itself... (and preferably versioned, something like "build-1.1" ?)

If you want to learn about GNU and Linux packaging, there's: http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/

> To recompile the application, from the command line enter ...
> 
>   dmd @build.rsp
> 
> If you have the compiler in your path and the standard configuration file, this should work just fine. Otherwise you might need to tweak it.

Since ".rsp" uses the Windows-centric .obj suffix, it didn't work...

Note: the suffix for libraries on Linux and others (e.g like Darwin) is wrong. Where Windows uses "PHOBOS.LIB", it would be "libphobos.a"

> If you use the -V switch, you will get a lot of information about the decisions it is making for this run.

Here's what I got, after proper patching:

*** build v1.1 (build 140)***
Compiler installed in /opt/gdc/bin/
Configuration File installed in /opt/gdc/bin/
Active Version: 'build'
Active Version: 'PPC'
Active Version: 'darwin'
Active Version: 'BigEndian'

The config file was really "", but it replaced
that with something from PATH environment ?
Note: GDC does not use a dmd.conf config file...

> **** NOTE **** This is only version 1.0, and thus will have mistakes in it and some missing functionality. Please let me know about anything that needs improvement. Eventually, I'll get this onto DSource.org as a project and we can then use SVN to manage the source modifications.

1.
The code uses a *lot* of "meaningless type aliases"
(term from http://www.digitalmars.com/d/dstyle.html)

Such as:
> alias char      CharN; // utf8  (Narrow)
> alias CharN[]   StringN; // utf8  (Narrow)

This just makes it look Hungarian, and hard to follow...

2.
It also uses a lot of extra semicolons (one per brace ?!?)
This is just an error, and should probably even be flagged

>         if ( lAllExist == false)
>         {
>             throw new Exception ("Not all supplied files exist.");
>         };

>     foreach( StringN lFile; vCmdLineFiles)
>     {
>         new Source(GetFullPathname(lFile));
>     };

There should *not* be a semicolon after the terminating
brace of: if, foreach, and similar block statements...
Single statements have semicolons, but blocks do not
(and structs and classes don't either, in D at least)

> Finally, this tool is useful to me, but that doesn't mean that you will find it useful for yourself. If you don't like it, then don't use it. I won't mind at all.

Patch to make it compile on Mac OS X is attached.

It uses the same old copy-and-paste linux-to-darwin
method that D seems to prefer for versioning ? <sigh>
(where is that version(Posix) now that we need it...)

Currently it doesn't work, since it wants to find
and compile for instance "std/stdio.d" - but fails.
It can probably be teached to ignore /opt/gdc/include/d

--anders

On Sun, 20 Feb 2005 21:17:04 +0100, Anders F Björklund wrote:

> Derek wrote:
> 
>> The source code is now available for the build utility I've been working on.
>> 
>>   http://www.users.bigpond.com/ddparnell/build.zip
>> 
>> This contains a number of source files, a Windows executable (build.exe), and some files to recompile the application.
>> 
>> First, extract all the files from the zip into a single directory.
> 
> This directory should be a part of the zipfile itself... (and preferably versioned, something like "build-1.1" ?)

Why? I didn't want to dictate to people what they should call their directory on their system. As far as being a requirement for 'build', the directory name that the utility is in, is immaterial. So why force people to use a name that I choose. It isn't polite.

However, it would have been a good idea to place the version number into the ZIP file name.

> If you want to learn about GNU and Linux packaging, there's: http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/

When and if I ever release something into the linux world, I'll consider reading this stuff. I don't do linux, simply because I haven't got it. I do Windows because that's what I've got. And I definitely have not got an Apple to work on, even though I'll gladly accept any donations of one ;-)

>> To recompile the application, from the command line enter ...
>> 
>>   dmd @build.rsp
>> 
>> If you have the compiler in your path and the standard configuration file, this should work just fine. Otherwise you might need to tweak it.
> 
> Since ".rsp" uses the Windows-centric .obj suffix, it didn't work...

Then get Windows ;-) I said that I only have Windows, so you other people will just have to deal with my lack of scope.

> Note: the suffix for libraries on Linux and others (e.g like Darwin) is wrong. Where Windows uses "PHOBOS.LIB", it would be "libphobos.a"

That's nice. Thanks for the heads-up.

>> If you use the -V switch, you will get a lot of information about the decisions it is making for this run.
> 
> Here's what I got, after proper patching:
> 
> *** build v1.1 (build 140)***
> Compiler installed in /opt/gdc/bin/
> Configuration File installed in /opt/gdc/bin/
> Active Version: 'build'
> Active Version: 'PPC'
> Active Version: 'darwin'
> Active Version: 'BigEndian'
> 
> The config file was really "", but it replaced
> that with something from PATH environment ?

And how would 'build' know that? Did you use the -CFPATH switch?

> Note: GDC does not use a dmd.conf config file...

And 'build' is not designed for GDC (yet). It is only supposed to work with
the compiler tools from DigitalMars. Sorry if I mislead you.

>> **** NOTE **** This is only version 1.0, and thus will have mistakes in it and some missing functionality. Please let me know about anything that needs improvement. Eventually, I'll get this onto DSource.org as a project and we can then use SVN to manage the source modifications.
> 
> 1.
> The code uses a *lot* of "meaningless type aliases"
> (term from http://www.digitalmars.com/d/dstyle.html)
> 
> Such as:
>> alias char      CharN; // utf8  (Narrow)
>> alias CharN[]   StringN; // utf8  (Narrow)
> 
> This just makes it look Hungarian, and hard to follow...

In your humble opinion.

The reasons for doing this were to create some consistent naming, given the lack of an official string type, and as a bit of an experiment. So instead of having ...

char, wchar, dchar, char[], wchar[] and dchar[]

I said to myself, "what if utf32 were considered the norm?". So I came up with ...

CharN, CharW, Char, StringN, StringW, and String.

Sorry you don't like it, but I've given up trying to please everybody all the time.

> 2.
> It also uses a lot of extra semicolons (one per brace ?!?)
> This is just an error, and should probably even be flagged

It is not an *error* as the compiler did not complain, and the specifications do not call it an error either.

It is a style of writing D code; one that you seem to somewhat dislike.

>>         if ( lAllExist == false)
>>         {
>>             throw new Exception ("Not all supplied files exist.");
>>         };

The purpose of placing a semi-colon in such cases is to give a visual clue to the reader that nothing else follows in the same statement, and to give a mental 'break' for the reader. It has a similar purpose to the 'period' at the end of English sentences. It is particularly useful in the 'if' statement as it explicitly tells the reader that there is no 'else' clause.

Upon seeing the semi-colon, one does a quick context shift to prepare for the next statement to read.

>>     foreach( StringN lFile; vCmdLineFiles)
>>     {
>>         new Source(GetFullPathname(lFile));
>>     };
> 
> There should *not* be a semicolon after the terminating brace of: if, foreach, and similar block statements...

Why? What harm does it do and/or what good is not having it?

> Single statements have semicolons, but blocks do not
> (and structs and classes don't either, in D at least)

Why? At best one can say that blocks do not require semi-colons. And BTW,
one can have semi-colons at the end of structs and classes in D.

>> Finally, this tool is useful to me, but that doesn't mean that you will find it useful for yourself. If you don't like it, then don't use it. I won't mind at all.
> 
> Patch to make it compile on Mac OS X is attached.

Thank you. May I incorporate it in to my version?

> It uses the same old copy-and-paste linux-to-darwin
> method that D seems to prefer for versioning ? <sigh>
> (where is that version(Posix) now that we need it...)
> 
> Currently it doesn't work, since it wants to find
> and compile for instance "std/stdio.d" - but fails.
> It can probably be teached to ignore /opt/gdc/include/d

Yes it can, however if that is normal for GDC then when I get around to supporting GDC I can make this behaviour a default one.

-- 
Derek
Melbourne, Australia

Derek wrote:

> Why? I didn't want to dictate to people what they should call their
> directory on their system. As far as being a requirement for 'build', the
> directory name that the utility is in, is immaterial. So why force people
> to use a name that I choose. It isn't polite.

Well, when I use "unzip" it dumps a bunch of files in my root dir...
And I don't like that :-) (but it's not really that big a deal to me)

> When and if I ever release something into the linux world, I'll consider
> reading this stuff. I don't do linux, simply because I haven't got it. I do
> Windows because that's what I've got. And I definitely have not got an
> Apple to work on, even though I'll gladly accept any donations of one ;-)

You don't really have to own one yourself, just read up on SSH :-)

> Then get Windows ;-) I said that I only have Windows, so you other people
> will just have to deal with my lack of scope.

Np, it was straightforward to just compile the .d source files.

>>The config file was really "", but it replaced
>>that with something from PATH environment ?
> 
> And how would 'build' know that? Did you use the -CFPATH switch? 

I hardcoded configpath to "", but it got filled out anyway ?

> And 'build' is not designed for GDC (yet). It is only supposed to work with
> the compiler tools from DigitalMars. Sorry if I mislead you.

Nah, I figured as much. Just thought you liked to know...
I just added a version(DigitalMars) to ReadConfigFile.

>>This just makes it look Hungarian, and hard to follow...
> 
> In your humble opinion.

Naturally :-) (I'm using a few local aliases myself)

>>It also uses a lot of extra semicolons (one per brace ?!?)
>>This is just an error, and should probably even be flagged
> 
> It is not an *error* as the compiler did not complain, and the
> specifications do not call it an error either.

Fair enough. (it's not a real DMD compiler error. Yet.)

> The purpose of placing a semi-colon in such cases is to give a visual clue
> to the reader that nothing else follows in the same statement, and to give
> a mental 'break' for the reader. It has a similar purpose to the 'period'
> at the end of English sentences. It is particularly useful in the 'if'
> statement as it explicitly tells the reader that there is no 'else' clause.

Had never seen this before. And it also gives the compiler a "break" by inserting a no-op after the block, but that's easy enough to optimize...

>>There should *not* be a semicolon after the terminating
>>brace of: if, foreach, and similar block statements...
> 
> Why? What harm does it do and/or what good is not having it?

It's ugly :-) It's also not in the D specification:
http://www.digitalmars.com/d/statement.html#block

But I have a feeling debating this will just lead to a
another Holy War, so I'll try to not mention it again...
(But it's the weirdest Brace Style that I've encountered)

>>Single statements have semicolons, but blocks do not
>>(and structs and classes don't either, in D at least)
> 
> Why? At best one can say that blocks do not require semi-colons. And BTW,
> one can have semi-colons at the end of structs and classes in D.

At least at the time being... They might all become errors.
Even if allowed at the moment, extra semis are still wrong.

>>Patch to make it compile on Mac OS X is attached.
> 
> Thank you. May I incorporate it in to my version?

Sure, that was the meaning all along of posting it.

> Yes it can, however if that is normal for GDC then when I get around to
> supporting GDC I can make this behaviour a default one.

It is, although the /opt/gdc part might vary...

--anders

On Sun, 20 Feb 2005 23:20:25 +0100, Anders F Björklund wrote:

> Derek wrote:
> 
>> Why? I didn't want to dictate to people what they should call their directory on their system. As far as being a requirement for 'build', the directory name that the utility is in, is immaterial. So why force people to use a name that I choose. It isn't polite.
> 
> Well, when I use "unzip" it dumps a bunch of files in my root dir...
> And I don't like that :-) (but it's not really that big a deal to me)

You're kidding! The tools that I use to unzip a file always ask me where
I'd like it to be unzipped to. And if the directory that I name doesn't
exist, they silently create it for me. Very user-friendly.

-- 
Derek
Melbourne, Australia
21/02/2005 10:42:02 AM

On Sun, 20 Feb 2005 21:17:04 +0100, Anders F Björklund wrote:


[snip]

> Patch to make it compile on Mac OS X is attached.
> 
> It uses the same old copy-and-paste linux-to-darwin
> method that D seems to prefer for versioning ? <sigh>
> (where is that version(Posix) now that we need it...)

Can't you do this sort of thing in your code ...

  version(linux)  version = Posix;
  version(darwin) version = Posix;

  version(Posix) {
    . . .
  }

-- 
Derek
Melbourne, Australia
21/02/2005 11:22:10 AM

I really see no point in the way you've been criticising the source code, Anders. The build tool is an open project.  Derek contributed a hefty amount of work/time to get it out there for the rest of us to play with. If you don't like the style, change it to the way you like it for your own personal use.  "build" is still a proof-of-concept, I think.  It's an example of what a build tool for D can evolve into.

If it gets on as a project on dsource.org where more than one person can contribute, perhaps that's the time to discuss coding style.

But until then, it's probably not wise to discourage new contributions with such pettiness.


On Sun, 20 Feb 2005 23:20:25 +0100, Anders F Björklund wrote:

> Derek wrote:
> 
>> Why? I didn't want to dictate to people what they should call their directory on their system. As far as being a requirement for 'build', the directory name that the utility is in, is immaterial. So why force people to use a name that I choose. It isn't polite.
> 
> Well, when I use "unzip" it dumps a bunch of files in my root dir...
> And I don't like that :-) (but it's not really that big a deal to me)
> 
>> When and if I ever release something into the linux world, I'll consider reading this stuff. I don't do linux, simply because I haven't got it. I do Windows because that's what I've got. And I definitely have not got an Apple to work on, even though I'll gladly accept any donations of one ;-)
> 
> You don't really have to own one yourself, just read up on SSH :-)
> 
>> Then get Windows ;-) I said that I only have Windows, so you other people will just have to deal with my lack of scope.
> 
> Np, it was straightforward to just compile the .d source files.
> 
>>>The config file was really "", but it replaced
>>>that with something from PATH environment ?
>> 
>> And how would 'build' know that? Did you use the -CFPATH switch?
> 
> I hardcoded configpath to "", but it got filled out anyway ?
> 
>> And 'build' is not designed for GDC (yet). It is only supposed to work with the compiler tools from DigitalMars. Sorry if I mislead you.
> 
> Nah, I figured as much. Just thought you liked to know...
> I just added a version(DigitalMars) to ReadConfigFile.
> 
>>>This just makes it look Hungarian, and hard to follow...
>> 
>> In your humble opinion.
> 
> Naturally :-) (I'm using a few local aliases myself)
> 
>>>It also uses a lot of extra semicolons (one per brace ?!?) This is just an error, and should probably even be flagged
>> 
>> It is not an *error* as the compiler did not complain, and the specifications do not call it an error either.
> 
> Fair enough. (it's not a real DMD compiler error. Yet.)
> 
>> The purpose of placing a semi-colon in such cases is to give a visual clue to the reader that nothing else follows in the same statement, and to give a mental 'break' for the reader. It has a similar purpose to the 'period' at the end of English sentences. It is particularly useful in the 'if' statement as it explicitly tells the reader that there is no 'else' clause.
> 
> Had never seen this before. And it also gives the compiler a "break" by inserting a no-op after the block, but that's easy enough to optimize...
> 
>>>There should *not* be a semicolon after the terminating brace of: if, foreach, and similar block statements...
>> 
>> Why? What harm does it do and/or what good is not having it?
> 
> It's ugly :-) It's also not in the D specification: http://www.digitalmars.com/d/statement.html#block
> 
> But I have a feeling debating this will just lead to a another Holy War, so I'll try to not mention it again... (But it's the weirdest Brace Style that I've encountered)
> 
>>>Single statements have semicolons, but blocks do not
>>>(and structs and classes don't either, in D at least)
>> 
>> Why? At best one can say that blocks do not require semi-colons. And BTW, one can have semi-colons at the end of structs and classes in D.
> 
> At least at the time being... They might all become errors. Even if allowed at the moment, extra semis are still wrong.
> 
>>>Patch to make it compile on Mac OS X is attached.
>> 
>> Thank you. May I incorporate it in to my version?
> 
> Sure, that was the meaning all along of posting it.
> 
>> Yes it can, however if that is normal for GDC then when I get around to supporting GDC I can make this behaviour a default one.
> 
> It is, although the /opt/gdc part might vary...
> 
> --anders

In article <i55xx7aue55v.5kg5ctpp4hlc$.dlg@40tude.net>, Derek Parnell says...
>
>On Sun, 20 Feb 2005 23:20:25 +0100, Anders F Björklund wrote:
>
>> Derek wrote:
>> 
>>> Why? I didn't want to dictate to people what they should call their directory on their system. As far as being a requirement for 'build', the directory name that the utility is in, is immaterial. So why force people to use a name that I choose. It isn't polite.
>> 
>> Well, when I use "unzip" it dumps a bunch of files in my root dir...
>> And I don't like that :-) (but it's not really that big a deal to me)
>
>You're kidding! The tools that I use to unzip a file always ask me where I'd like it to be unzipped to. And if the directory that I name doesn't exist, they silently create it for me. Very user-friendly.
> 
>-- 
>Derek
>Melbourne, Australia
>21/02/2005 10:42:02 AM

By default Unix unzip utilities unzip to the current directory. That's why when I'm on unix I always make a directory and cd into it before unzipping or use the -d flag to create a dir and unzip into that.

John Reimer wrote:

> I really see no point in the way you've been criticising the source code,
> Anders. The build tool is an open project.  Derek contributed a hefty
> amount of work/time to get it out there for the rest of us to play with.

Sorry, it was all just meant as constructive criticism...

> If you don't like the style, change it to the way you like it for your own
> personal use.  "build" is still a proof-of-concept, I think.  It's an
> example of what a build tool for D can evolve into.

Yeah, that was why I tried to port it to GDC and Darwin ?

> If it gets on as a project on dsource.org where more than one person can
> contribute, perhaps that's the time to discuss coding style.
> 
> But until then, it's probably not wise to discourage new contributions
> with such pettiness.

Too used to working on community projects, I suppose.
http://c2.com/cgi/wiki?CollectiveCodeOwnership

Hope that Derek wasn't too put off or discouraged...
I just happen to think that how code looks is important.

--anders