www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - build utility v1.0

reply Derek <derek psych.ward> writes:
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. 
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.

There are a number of source files in the form "*_bn.d". These are
automatically maintained by build so don't edit them. These are
automatically incremented build numbers for a module. To get build to
maintain a build number file, insert into each module you need it for ...

private import <modulename>_bn;

Your code can then access the build number for the module like this ...

   writefln("Module Build Number %d", auto_build_number);


To see the command line parameters and switches, just run build without
anything else on the command line. You should get something like ...

Path and Version : F:\Projects\build\build.exe v1.0(115)
Usage: build sourcefile [options objectfiles libraries]
  sourcefile D source file
  -v         Verbose (passed through to D)
  -V         Verbose (NOT passed through)
  -DCPATH<path> <path> is where the compiler has been installed.
             Only needed if the compiler is not in the system's
             PATH list. Used if you are testing an alternate
             version of the compiler.
  -CFPATH<path> <path> is where the D config file has been installed.
  -full      Causes all source files, except ignored modules,
              to be compiled.
  -link      Forces the linker to be called instead of the librarian.
              (Only needed if the source files do not contain
               main/WinMain)
  -nolink    Ensures that the linker is not called.
              (Only needed if main/WinMain is found in the source
               files and you do NOT want an executable created.)
  -lib       Forces the object files to be placed in a library.
              (Only needed if main/WinMain is found in the source
               files AND you want it in a library instead of
               an executable.)
  -nolib     Ensures that the object files are not used to form
              a library.
              (Only needed if main/WinMain is not found in the source
               files and you do NOT want a library.
  -allobj    Ensures that all object files are added to a
              library.
              (Normally only those in the same directory are added.)
  -cleanup   Ensures that all object files created during the run
              are removed at the end of the run, plus other work files.
  -gui       Forces a GUI application to be created.
              (Only needed if WinMain is not found in the source files.)
  -X<module> Modules to ignore (eg. -Xmylib)
  -M<module> Modules to notice (eg. -Mphobos)
  [...]      All other options, objectfiles and libraries are
              passed to the compiler


The idea of 'build' is to give it the top-level source code file for your
application, and it will then work out all the dependencies and which files
are need to be recompiled. Typically it is run from a command prompt like
...

   build myapp

Which will then create myapp.exe (for Windows) based on the imports
contained in the related sources.

If it finds a function called either 'main' or 'WinMain' it will assume you
want to create an executable. If it doesn't find this, it assumes you want
to create a library. 

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

**** 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.

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.

-- 
Derek
Melbourne, Australia
Feb 12 2005
next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
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. 
 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.
 
 There are a number of source files in the form "*_bn.d". These are
 automatically maintained by build so don't edit them. These are
 automatically incremented build numbers for a module. To get build to
 maintain a build number file, insert into each module you need it for ...
 
 private import <modulename>_bn;
 
 Your code can then access the build number for the module like this ...
 
    writefln("Module Build Number %d", auto_build_number);
 
 
 To see the command line parameters and switches, just run build without
 anything else on the command line. You should get something like ...
 
 Path and Version : F:\Projects\build\build.exe v1.0(115)
 Usage: build sourcefile [options objectfiles libraries]
   sourcefile D source file
   -v         Verbose (passed through to D)
   -V         Verbose (NOT passed through)
   -DCPATH<path> <path> is where the compiler has been installed.
              Only needed if the compiler is not in the system's
              PATH list. Used if you are testing an alternate
              version of the compiler.
   -CFPATH<path> <path> is where the D config file has been installed.
   -full      Causes all source files, except ignored modules,
               to be compiled.
   -link      Forces the linker to be called instead of the librarian.
               (Only needed if the source files do not contain
                main/WinMain)
   -nolink    Ensures that the linker is not called.
               (Only needed if main/WinMain is found in the source
                files and you do NOT want an executable created.)
   -lib       Forces the object files to be placed in a library.
               (Only needed if main/WinMain is found in the source
                files AND you want it in a library instead of
                an executable.)
   -nolib     Ensures that the object files are not used to form
               a library.
               (Only needed if main/WinMain is not found in the source
                files and you do NOT want a library.
   -allobj    Ensures that all object files are added to a
               library.
               (Normally only those in the same directory are added.)
   -cleanup   Ensures that all object files created during the run
               are removed at the end of the run, plus other work files.
   -gui       Forces a GUI application to be created.
               (Only needed if WinMain is not found in the source files.)
   -X<module> Modules to ignore (eg. -Xmylib)
   -M<module> Modules to notice (eg. -Mphobos)
   [...]      All other options, objectfiles and libraries are
               passed to the compiler
 
 
 The idea of 'build' is to give it the top-level source code file for your
 application, and it will then work out all the dependencies and which files
 are need to be recompiled. Typically it is run from a command prompt like
 ...
 
    build myapp
 
 Which will then create myapp.exe (for Windows) based on the imports
 contained in the related sources.
 
 If it finds a function called either 'main' or 'WinMain' it will assume you
 want to create an executable. If it doesn't find this, it assumes you want
 to create a library. 
 
 If you use the -V switch, you will get a lot of information about the
 decisions it is making for this run. 
 
 **** 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.
 
 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.
 


Thanks, Derek!

I guess the Linux version is left as a project for the reader, then? :-)

I had made some changes to the previous version you sent me to get it 
running properly on Linux.  Perhaps I just have to merge those in again.

Looks good.

- John R.
Feb 12 2005
parent Derek <derek psych.ward> writes:
On Sat, 12 Feb 2005 11:33:24 -0800, John Reimer wrote:


 Derek wrote:

 The source code is now available for the build utility I've been working
 on.
 




[snip]

 
 Thanks, Derek!
 
 I guess the Linux version is left as a project for the reader, then? :-)


Yeah, I guess so. I don't have linux and I just guessed at some stuff based
on my ancient System V Unix days.
 

 I had made some changes to the previous version you sent me to get it 
 running properly on Linux.  Perhaps I just have to merge those in again.


That would be nice. Just sent the changes to me and I'll merge them with my
copy. (I really must get this to the dsource.org project).

-- 
Derek
Melbourne, Australia
Feb 12 2005
prev sibling next sibling parent zwang <nehzgnaw gmail.com> writes:
Nice! I'll give it a try today.
Thank you, Derek!


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. 
 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.
 
 There are a number of source files in the form "*_bn.d". These are
 automatically maintained by build so don't edit them. These are
 automatically incremented build numbers for a module. To get build to
 maintain a build number file, insert into each module you need it for ...
 
 private import <modulename>_bn;
 
 Your code can then access the build number for the module like this ...
 
    writefln("Module Build Number %d", auto_build_number);
 
 
 To see the command line parameters and switches, just run build without
 anything else on the command line. You should get something like ...
 
 Path and Version : F:\Projects\build\build.exe v1.0(115)
 Usage: build sourcefile [options objectfiles libraries]
   sourcefile D source file
   -v         Verbose (passed through to D)
   -V         Verbose (NOT passed through)
   -DCPATH<path> <path> is where the compiler has been installed.
              Only needed if the compiler is not in the system's
              PATH list. Used if you are testing an alternate
              version of the compiler.
   -CFPATH<path> <path> is where the D config file has been installed.
   -full      Causes all source files, except ignored modules,
               to be compiled.
   -link      Forces the linker to be called instead of the librarian.
               (Only needed if the source files do not contain
                main/WinMain)
   -nolink    Ensures that the linker is not called.
               (Only needed if main/WinMain is found in the source
                files and you do NOT want an executable created.)
   -lib       Forces the object files to be placed in a library.
               (Only needed if main/WinMain is found in the source
                files AND you want it in a library instead of
                an executable.)
   -nolib     Ensures that the object files are not used to form
               a library.
               (Only needed if main/WinMain is not found in the source
                files and you do NOT want a library.
   -allobj    Ensures that all object files are added to a
               library.
               (Normally only those in the same directory are added.)
   -cleanup   Ensures that all object files created during the run
               are removed at the end of the run, plus other work files.
   -gui       Forces a GUI application to be created.
               (Only needed if WinMain is not found in the source files.)
   -X<module> Modules to ignore (eg. -Xmylib)
   -M<module> Modules to notice (eg. -Mphobos)
   [...]      All other options, objectfiles and libraries are
               passed to the compiler
 
 
 The idea of 'build' is to give it the top-level source code file for your
 application, and it will then work out all the dependencies and which files
 are need to be recompiled. Typically it is run from a command prompt like
 ...
 
    build myapp
 
 Which will then create myapp.exe (for Windows) based on the imports
 contained in the related sources.
 
 If it finds a function called either 'main' or 'WinMain' it will assume you
 want to create an executable. If it doesn't find this, it assumes you want
 to create a library. 
 
 If you use the -V switch, you will get a lot of information about the
 decisions it is making for this run. 
 
 **** 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.
 
 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.
Feb 12 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Derek" <derek psych.ward> wrote in message 
news:1bedfvi3tsc3c.1cy4hq7de8ni4$.dlg 40tude.net...

 The source code is now available for the build utility I've been working
 on.

  http://www.users.bigpond.com/ddparnell/build.zip


Is there a list of pragmas that build.exe understands?
Feb 14 2005
parent Derek Parnell <derek psych.ward> writes:
On Mon, 14 Feb 2005 10:46:34 -0500, Ben Hinkle wrote:


 "Derek" <derek psych.ward> wrote in message 
 news:1bedfvi3tsc3c.1cy4hq7de8ni4$.dlg 40tude.net...

 The source code is now available for the build utility I've been working
 on.

  http://www.users.bigpond.com/ddparnell/build.zip


 
 Is there a list of pragmas that build.exe understands?


Sorry, I left out the doc files from the ZIP file. They are there now in
HTML format. Unzip the download and click on INDEX.HTM to see the docs.

-- 
Derek
Melbourne, Australia
15/02/2005 1:02:34 PM
Feb 14 2005
prev sibling next sibling parent reply "Nick Sabalausky" <z a.a> writes:
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?

"Derek" <derek psych.ward> wrote in message 
news:1bedfvi3tsc3c.1cy4hq7de8ni4$.dlg 40tude.net...

 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.
 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.

 There are a number of source files in the form "*_bn.d". These are
 automatically maintained by build so don't edit them. These are
 automatically incremented build numbers for a module. To get build to
 maintain a build number file, insert into each module you need it for ...

 private import <modulename>_bn;

 Your code can then access the build number for the module like this ...

   writefln("Module Build Number %d", auto_build_number);


 To see the command line parameters and switches, just run build without
 anything else on the command line. You should get something like ...

 Path and Version : F:\Projects\build\build.exe v1.0(115)
 Usage: build sourcefile [options objectfiles libraries]
  sourcefile D source file
  -v         Verbose (passed through to D)
  -V         Verbose (NOT passed through)
  -DCPATH<path> <path> is where the compiler has been installed.
             Only needed if the compiler is not in the system's
             PATH list. Used if you are testing an alternate
             version of the compiler.
  -CFPATH<path> <path> is where the D config file has been installed.
  -full      Causes all source files, except ignored modules,
              to be compiled.
  -link      Forces the linker to be called instead of the librarian.
              (Only needed if the source files do not contain
               main/WinMain)
  -nolink    Ensures that the linker is not called.
              (Only needed if main/WinMain is found in the source
               files and you do NOT want an executable created.)
  -lib       Forces the object files to be placed in a library.
              (Only needed if main/WinMain is found in the source
               files AND you want it in a library instead of
               an executable.)
  -nolib     Ensures that the object files are not used to form
              a library.
              (Only needed if main/WinMain is not found in the source
               files and you do NOT want a library.
  -allobj    Ensures that all object files are added to a
              library.
              (Normally only those in the same directory are added.)
  -cleanup   Ensures that all object files created during the run
              are removed at the end of the run, plus other work files.
  -gui       Forces a GUI application to be created.
              (Only needed if WinMain is not found in the source files.)
  -X<module> Modules to ignore (eg. -Xmylib)
  -M<module> Modules to notice (eg. -Mphobos)
  [...]      All other options, objectfiles and libraries are
              passed to the compiler


 The idea of 'build' is to give it the top-level source code file for your
 application, and it will then work out all the dependencies and which 
 files
 are need to be recompiled. Typically it is run from a command prompt like
 ...

   build myapp

 Which will then create myapp.exe (for Windows) based on the imports
 contained in the related sources.

 If it finds a function called either 'main' or 'WinMain' it will assume 
 you
 want to create an executable. If it doesn't find this, it assumes you want
 to create a library.

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

 **** 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.

 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.

 -- 
 Derek
 Melbourne, Australia
Feb 14 2005
next sibling parent reply "Nick Sabalausky" <z a.a> writes:
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.

I did find one bug though.  It hangs when it finds /+ +/ style comments in a 
source.

"Nick Sabalausky" <z a.a> wrote in message 
news:cur049$1nsp$1 digitaldaemon.com...

 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?

 "Derek" <derek psych.ward> wrote in message 
 news:1bedfvi3tsc3c.1cy4hq7de8ni4$.dlg 40tude.net...

 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.
 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.

 There are a number of source files in the form "*_bn.d". These are
 automatically maintained by build so don't edit them. These are
 automatically incremented build numbers for a module. To get build to
 maintain a build number file, insert into each module you need it for ...

 private import <modulename>_bn;

 Your code can then access the build number for the module like this ...

   writefln("Module Build Number %d", auto_build_number);


 To see the command line parameters and switches, just run build without
 anything else on the command line. You should get something like ...

 Path and Version : F:\Projects\build\build.exe v1.0(115)
 Usage: build sourcefile [options objectfiles libraries]
  sourcefile D source file
  -v         Verbose (passed through to D)
  -V         Verbose (NOT passed through)
  -DCPATH<path> <path> is where the compiler has been installed.
             Only needed if the compiler is not in the system's
             PATH list. Used if you are testing an alternate
             version of the compiler.
  -CFPATH<path> <path> is where the D config file has been installed.
  -full      Causes all source files, except ignored modules,
              to be compiled.
  -link      Forces the linker to be called instead of the librarian.
              (Only needed if the source files do not contain
               main/WinMain)
  -nolink    Ensures that the linker is not called.
              (Only needed if main/WinMain is found in the source
               files and you do NOT want an executable created.)
  -lib       Forces the object files to be placed in a library.
              (Only needed if main/WinMain is found in the source
               files AND you want it in a library instead of
               an executable.)
  -nolib     Ensures that the object files are not used to form
              a library.
              (Only needed if main/WinMain is not found in the source
               files and you do NOT want a library.
  -allobj    Ensures that all object files are added to a
              library.
              (Normally only those in the same directory are added.)
  -cleanup   Ensures that all object files created during the run
              are removed at the end of the run, plus other work files.
  -gui       Forces a GUI application to be created.
              (Only needed if WinMain is not found in the source files.)
  -X<module> Modules to ignore (eg. -Xmylib)
  -M<module> Modules to notice (eg. -Mphobos)
  [...]      All other options, objectfiles and libraries are
              passed to the compiler


 The idea of 'build' is to give it the top-level source code file for your
 application, and it will then work out all the dependencies and which 
 files
 are need to be recompiled. Typically it is run from a command prompt like
 ...

   build myapp

 Which will then create myapp.exe (for Windows) based on the imports
 contained in the related sources.

 If it finds a function called either 'main' or 'WinMain' it will assume 
 you
 want to create an executable. If it doesn't find this, it assumes you 
 want
 to create a library.

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

 **** 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.

 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.

 -- 
 Derek
 Melbourne, Australia
Feb 14 2005
parent reply Derek Parnell <derek psych.ward> writes:
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
Feb 14 2005
parent "Nick Sabalausky" <z a.a> writes:
"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.
Feb 14 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
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
Feb 14 2005
parent "Nick Sabalausky" <z a.a> writes:
"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 ;)
Feb 14 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Feb 20 2005
next sibling parent reply Derek <derek psych.ward> writes:
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
Feb 20 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Feb 20 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
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
Feb 20 2005
parent Ben Hinkle <Ben_member pathlink.com> writes:
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.
Feb 20 2005
prev sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
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
Feb 20 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Feb 20 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 21 Feb 2005 08:03:09 +0100, Anders F Björklund wrote:


 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...


It was, even though the tone might have been a bit strong for some.


 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 ?


Thanks for doing that. Does my ...

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

idea work for you?
 

 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


I'm also used to working with project teams, both small and largish (60+
people). 


 Hope that Derek wasn't too put off or discouraged...


Not at all. I've already added your patches. I've removed all those
instances of superfluous semi-colons and removed the 'redundant' aliases. 

I'm preparing to start this up as a DSOURCE.ORG project. 


 I just happen to think that how code looks is important.


And so do I, that's why I deliberately inserted all those semi-colons and
aliases in the first place ;-)

-- 
Derek
Melbourne, Australia
21/02/2005 6:13:16 PM
Feb 20 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


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


 
 It was, even though the tone might have been a bit strong for some.


Just consider it a Swedish personality trait, not ignorance :-)

(English is not my native language, as with a lot of people here)


   version(darwin) version = Posix;
   version(linux) version = Posix;
 
 idea work for you?


It's part of a bigger problem, and needs a more permanent change...

It kinda works, just that a) it needs to be repeated in every single
project and b) the code imports and uses std.c.linux.linux module
(which needs to be changed into std.c.darwin.darwin, for instance)

But it's a different discussion...
(and Mac OS X is not a supported DMD platform, it's just a GDC one)


Hope that Derek wasn't too put off or discouraged...


 
 Not at all. I've already added your patches. I've removed all those
 instances of superfluous semi-colons and removed the 'redundant' aliases. 


Ok, hope I'm not "cramping your style" here or anything ?
Maybe it is my code that needs adapting to local customs.


 And so do I, that's why I deliberately inserted all those semi-colons and
 aliases in the first place ;-)


:-)

--anders
Feb 20 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
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
Feb 20 2005
prev sibling parent reply Manfred Hansen <manfred toppoint.de> writes:
Hello,

i can't find the build programm. 
Have you change the url?

mfg Manfred

Am Sun, 13 Feb 2005 01:21:56 +1100 schrieb Derek:


 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. 
 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.
 
 There are a number of source files in the form "*_bn.d". These are
 automatically maintained by build so don't edit them. These are
 automatically incremented build numbers for a module. To get build to
 maintain a build number file, insert into each module you need it for ...
 
 private import <modulename>_bn;
 
 Your code can then access the build number for the module like this ...
 
    writefln("Module Build Number %d", auto_build_number);
 
 
 To see the command line parameters and switches, just run build without
 anything else on the command line. You should get something like ...
 
 Path and Version : F:\Projects\build\build.exe v1.0(115)
 Usage: build sourcefile [options objectfiles libraries]
   sourcefile D source file
   -v         Verbose (passed through to D)
   -V         Verbose (NOT passed through)
   -DCPATH<path> <path> is where the compiler has been installed.
              Only needed if the compiler is not in the system's
              PATH list. Used if you are testing an alternate
              version of the compiler.
   -CFPATH<path> <path> is where the D config file has been installed.
   -full      Causes all source files, except ignored modules,
               to be compiled.
   -link      Forces the linker to be called instead of the librarian.
               (Only needed if the source files do not contain
                main/WinMain)
   -nolink    Ensures that the linker is not called.
               (Only needed if main/WinMain is found in the source
                files and you do NOT want an executable created.)
   -lib       Forces the object files to be placed in a library.
               (Only needed if main/WinMain is found in the source
                files AND you want it in a library instead of
                an executable.)
   -nolib     Ensures that the object files are not used to form
               a library.
               (Only needed if main/WinMain is not found in the source
                files and you do NOT want a library.
   -allobj    Ensures that all object files are added to a
               library.
               (Normally only those in the same directory are added.)
   -cleanup   Ensures that all object files created during the run
               are removed at the end of the run, plus other work files.
   -gui       Forces a GUI application to be created.
               (Only needed if WinMain is not found in the source files.)
   -X<module> Modules to ignore (eg. -Xmylib)
   -M<module> Modules to notice (eg. -Mphobos)
   [...]      All other options, objectfiles and libraries are
               passed to the compiler
 
 
 The idea of 'build' is to give it the top-level source code file for your
 application, and it will then work out all the dependencies and which files
 are need to be recompiled. Typically it is run from a command prompt like
 ...
 
    build myapp
 
 Which will then create myapp.exe (for Windows) based on the imports
 contained in the related sources.
 
 If it finds a function called either 'main' or 'WinMain' it will assume you
 want to create an executable. If it doesn't find this, it assumes you want
 to create a library. 
 
 If you use the -V switch, you will get a lot of information about the
 decisions it is making for this run. 
 
 **** 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.
 
 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.
Feb 26 2005
parent Derek <derek psych.ward> writes:
On Sat, 26 Feb 2005 18:47:37 +0100, Manfred Hansen wrote:


 Hello,
 
 i can't find the build programm. 
 Have you change the url?
 


Yes. It is now being hosted by the DSource project.

  http://www.dsource.org/projects/build

It is also at release level v1.5 now and appears fairly stable. 

-- 
Derek
Melbourne, Australia
Feb 26 2005