So ... - yet another wheel re-invented? Sure, re-invent make, like the people who invented ant, rake, dmake, nmake, and a lot of other tools. To learn how to plan a project, to learn how to write code, for fun, or just because you can.

(GNU) make works just fine for me for almost all of my build problems, from "hello world" up to complete embedded systems, it is properly documented, and has very few surprises. And because make "just" calls other utilities, I can use the entire Unix toolkit to get the job done.

Yes, the syntax is ugly, but not uglier or harder than shell scripts.

So, why should I spend my time learning a different tool?

Your tool calculates hashes instead of relying on timestamps. OK, but why? Comparing two currently unknown timestamps costs two system calls (stat()) and an integer compare. Comparing two currently unknown hashes costs at least three system calls (open(), read(), close()) plus a lot of bit shuffling <update>per file</update> plus comparing a block of memory typically larger than any native integer type. This is much more work, not less. As you store hashes in a separate file, you also need some extra open(), read(), close() and open(), write(), close() system calls to manage that file. Make keeps the timestamps in memory, the operating system updates the timestamps in the filesystem without needing a separate file.

Rebuild rules

Rebuilds will happen only if:

        1. a source file is new or has changed
        2. the corresponding object file is missing or has changed
        3. the command that is used to compile the source has changed
        4. a dependent header file has changed
        5. the command to link the executable or build the library arc
+hive has changed
        6. the executable or library has changed or is missing
[download]

Make does 1, 2, and 6 by default, 3 if the target also depends on the Makefile, 4 if dependencies are calculated before or during the make process (typically by using gcc -M in one make rule and including the output of that command into the Makefile), 5 if the target depends on the linker, archiver, compiler or whatever tool is used to build the target.

I expect a build tool to take care of 1, 2, 4, and 6. 3 is nice to have. 5 is nice to have for custom tools (build and) used in the project, but I don't see a use to track the linker or archiver executable, as they rarely change, at least on my systems. And when they change, I recompile the entire project from a clean state (make distclean; make).

FEATURES AND ADVANTAGES
     1. Everything is done with SHA1 signatures.  No dates are used an
+ywhere.
     2. bld is REALLY simple to use.  There are no arguments, no optio
+ns(except -h), no environment variables and no rc files.  The entire 
+bld is controlled from the Bld(and Bld.gv file) file.  Only a minimal
+ knowledge of perl is needed - variable definitions and simple regula
+r expressions.
     3. bld is not hierarchical.  A single Bld file controls the const
+ruction of a single target(a target is an executable or library(stati
+c or shared)).  Complex multi-target projects use one Bld.gv(global v
+alues) file and many Bld files - one to a target.
     4. Each source file will have three signatures associated with it
+ - one for the source file, one for the corresponding object file and
+ one for the cmds use to rebuild the source.  A change in any of thes
+e will result in a rebuild.
     5. If any files in the bld have the same signature this is warned
+ about e.g. two header or source files of the same or different names
+.
     6. Optionally, the signatures of dynamic libraries may be tracked
+.  If a library signature changes the bld may warn or stop the rebuil
+d.  If dynamic libraries are added or deleted from the bld this can i
+gnore/warn/fatal.
     7. A change in the target signature will result in a rebuild.
     8. Complex multi-target projects are built with a standard direct
+ory setup and a standard set of scripts - Directories:
[download]

1 - I don't get it. What's the advantage of calculating hashes of files and doing a lot of I/O and calculations over comparing timestamps?

2 - make is at least as simple to use. A single Makefile, and even that is optional for simple projects, thanks to the default rules. No perl knowledge needed:

/tmp>mkdir empty
/tmp>cd empty
/tmp/empty>echo 'int main() { write(1,"Hello\n",6); }' > demo.c
/tmp/empty>make demo
cc     demo.c   -o demo
/tmp/empty>./demo
Hello
/tmp/empty>ls
demo  demo.c
/tmp/empty>
[download]

3 - Being unable to handle a hierachical set of files is an advantage? Really?

4 - Neat idea. You can get the same result by adding dependencies to a target in a Makefile.

5 - Never heard of hash collisions? They are rare, but not impossible! Why are identical files a problem at all?

6 - Add dependencies to a target in the Makefile for this.

7 - Why? Who modifies the generated target?

Oh, wait: Some projects don't strip the generated executables. So I strip them manually. Is this a valid reason to recompile an unstripped executable? I don't think so.

8 - I really need that many files just to compile a few files?

Your Notes:

     1. bld assumes that a source will build a derived file e.g. .o fi
+les in the same directory and have the same root name as the source.

     2. bld assumes that all targets in multi-target bld's will be uni
+quely named - all targets go into the same project directory.

     3. Some projects violate either or both of these target naming or
+ object file naming/location requirements, but reconstructing these p
+rojects with bld should be relatively easy e.g. systemd.

     4. bld executes cmd fields({}) in the bld directory and then move
+s all created files to the source directory.
[download]

1 - make does the same, most times. ant seems to know more about javac (see below).

2 - This simply does not work with larger projects. As far as I know, subdirectories were re-invented for the last time in 1983, with MS-DOS 2.0.

3 - So I need to reorganize my project to use a single flat directory (or fake it by having unique names even across subdirectories)? Are you kidding me?

4 - Are you aware that javac (the Java compiler) has the nasty habbit of generating several output files from a single source file? Perl Modules need subdirectories to work. javadoc and several other tools generate a bunch of files including subdirectories full of files, and this structure must not be changed.

Some other problems I see:

• Keeping a hash (or timestamp) of just the compiler, linker, and archiver executables may be insufficient, as those executables often also link in libraries and call other executables that may change without a single bit change in the main executable or its meta data.
• system() function called with a single string, at least in your examples, so your tool will likely start messing with the shell. This is at least as ugly as in make and begs for trouble. Why do I need to quote variables for perl and then again for the shell? One set of quoting rules should be sufficient!
• No default rules? Do I really have to tell your tool how to compile an object file from a source file, and how to link object files to executables, over and over again? Make has default rules for everything and the kitchen sink, see output of env - make -f /dev/null -p.
• I need Perl before I can use your tool. Make works without Perl.

Alexander