@@ Need to create some show-case with some intermidiate compiler like
   idl/lex/yacc. M4 comes to mind.

%% Stages of building

   1. configure/configuration

   2. build/build

   3a. test/testing

   3b. install/installation

@@ Maybe I should have a special function for inclusion from special
   directories (like Build).

@@ it would nice to have suffixes configurable

@@ There could be a set of files to configure building environment (like
   suffixes of files, names of utilities, etc). If I decide to ship
   environment as standalon product I will have to somehow separate
   those files (like putting in different directories).

@@ It would make sense to split build system on subsystems like 'base'
   'c' 'cxx', 'corba/cxx' etc.

%% Maybe I should pre-load some commonly used patterns.

@@ Maybe makefiles that are not ment to be used interactively should
   inherit their interactivity status from their includer.

@@ Allow changing of options based on the category (plus all). This
   can be done like this:

   %.o : %.cpp : cxx_options = $(cxx_cpp_flags) $(cxx_debug_flags) $(cxx_diagnostic_flags)
   %.o : %.cpp : cxx_cpp_options :=
   %.o : %.cpp : cxx_debug_options := -g
   %.o : %.cpp : cxx_diagnostic_options := -Wall

   This will allow the user to change only what he want without much
   hassle.

@! Can I make a dependecy of lib.l on lib.so? Should I? Or should I list
   .so/.a in the pattern rule so it gets deleted?

@@ It would be nice to have a custom message for phony targets that merely
   depend on normal targets. For example if I could get a list of targets
   that were updated I would have been able to print such a message. This
   would probably require modifications to make.

   For default target of a dispatch makefile (better name?) I use directory
   name which makes perfect sense. BTW, maybe I should call them directory
   makefiles, or meta-makefiles, or stubs?

@@ Since the build of multiple goals in the same target can be tricky I
   may want to detect this and give a warning/error (this could be
   configurable).

@@ 'cxx' should depend on 'c'. 'cxx' can reuse ar facility from 'c'.

@@ Make function extension framework. The idea is to use $(shell) to call
   arbitrary executable/shell-script. The only problem is that I need a
   way to build something before continuing to read makefile. Something
   like .REQUIRE: target? When make sees this it stops reading makefile
   and tries to build the target. If build succeeded make resumes to
   read the makefile. If build failed make stops with an error.

   The other, more advanced, idea is to use dynamic loading of functions.
   This way it will be alot faster.

   If included makefiles could be rebuilt on the spot (i.e. without
   first reading the rest) then it would be a way.

@@ Can I use linker script instead of my .l library descriptor (or together
   with?).

@@ There is a support for 'version script' in ld. I wonder what is that.

@@ study linux kernel build system

@! Maybe clean/disfigure target should include deletion of a directory
   if (a) the build could potentially create it and (b) it is empty.
   This way things will be cleaner and, after saying make clean in the
   build directory, one gets just configuration.

@@ I can ask user if he wants to override default .a/.so search paths
   (for example to match the compiler).


@@ Multidir example probably belongs to c subsystem.

@@ If I have build-as-you-need-them makefile inclusion scheme then if I
   include makefiles in a proper order I can get rid of those
   'configuring blah-blah' messages.

@@ I can be cool and make 'ls' in cxx to find present c++ compilers. This
   way I will be able to distribute compiler-specific files separately.

@@ It would be nice to have include function that includes a file
   relatevely to the current's Makefile directory.

@@ Maybe factor out cpp as a common facility in 'c'? Right now I duplicate
   some support code in cxx/gnu and cxx/intel.

@@ All this '.l' abstraction support belongs to 'c'.

@@ In import/export stubs check for version compatibilities. Oohooo!

@@ What if I save src_root somewhere in out_root?

%% Need to try to use build with distcc. Works well.

@@ I may want to store src_root someweher in out_root so that I don't
   need to ask for it (will not work in all cases).

@! It is probably a good idea to make each file responsible for
   making sure its guts are included right number of times.

@! With introduction of .NOT_DEFAULT I can factor out aliasing into
   (per-project) bootstrap.make. Did in some projects - works well.
   Need to do them in example.

@@ foreach is a way to define local variable.

@! use $(< file) instead of cat

@! use last dir + relative path in messages

@! what about using few-letters vars instead of cxx_obj (o) cxx_od (d)?

@! How about uniform importing facility without any subsystems? For example
   CORBA is a translator and a library at the same time - how to handle it?

    - can use whatever names in imported files.

    - will need importing from project build dir and from bld_root

@! Need to think about hacker mode - passing config info via command line
   with standard names like CXX CPPFLAGS LDFLAGS, etc.

@! teach import stubs to not try include anything when cleaning/disfiguring?

@@ local target that will rebuild only local object files? Or maybe set an
   order of rebuilding local files first?

@! Now since I have .DEFAULT_TARGET I can do save/restore thing for export
   import. So there won't be a need to secure default target. Way too cool!

%% Usually src_root and out_root are the same. I should suggest one
   by default when asking user for it.
   
@@ There are two situations where I can guess src_root from out_root:
   first is when out_root == src_root (I can check for build/bootstrap.make
   though bootstrap.make can be named differently). The other case is when
   out_root already contains build project (I will need to kind of marker
   that contains value of src_root; maybe build/configuratio-dynamic.make).