Thread overview | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 12, 2005 build utility v1.0 | ||||
---|---|---|---|---|
| ||||
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 |
February 12, 2005 Re: build utility v1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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.
>
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.
|
February 12, 2005 Re: build utility v1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek | 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.
>
|
February 12, 2005 Re: build utility v1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | 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 |
February 14, 2005 Re: build utility v1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek | "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? |
February 14, 2005 Re: build utility v1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek | 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 |
February 14, 2005 Re: build utility v1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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 > > |
February 15, 2005 Re: build utility v1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | 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 |
February 15, 2005 Re: build utility v1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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 |
February 15, 2005 Re: build utility v1.0 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | 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 |
Copyright © 1999-2021 by the D Language Foundation