Start tracking build with git

1 files changed, 156 insertions, 0 deletions

diff --git a/documentation/IDEAS b/documentation/IDEAS
new file mode 100644
index 0000000..649f375
--- /dev/null
+++ b/documentation/IDEAS
@@ -0,0 +1,156 @@
+@@ 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).