From d7b7e218bfe92516f525568a6c1c9e1a9eb241fe Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Fri, 5 Feb 2010 18:01:45 +0200 Subject: Start tracking build with git --- documentation/IDEAS | 156 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 156 insertions(+) create mode 100644 documentation/IDEAS (limited to 'documentation/IDEAS') 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). -- cgit v1.1