STRUCTURE


VARIABLES

%% It would be nice to be able to include makefile in a way that
   variables are restored.

@% I definitely need some naming convention for "global" variables.
   Since I include potentially unknown makefiles (like library
   dependecies) I cannot predict what they do. This is another
   argument for variable framing.
   
   Some ideas:
   
    - Variables that start and end with '%' are considered global
      and system. Subsystems may define such vars if there is
      a real need. (Currently defined names should be documented
      here. Each subsystem should document names that it defines.)
      Subsystem should prefix each such var with its name (e.g. cxx_).
   
    - Variables that contain '-' are considered 'functions' and not
      framed. Generally subsystems should define those. The names
      should be chosen carefully in order not to cause name clashes.
      (Each subsystem should document names that it defines).
      Subsystem should prefix each such function with its name 
      (e.g. cxx-).
      
    - Variables that appear in %frame_exclude% are not framed. General 
      rule is to add only special one-word functions (usually defined
      by base subsystem) that are used often and thus having one-word
      terse name is very important; for example 'include' or 'import'
   

%% After the inclusion of dependency makefiles I cannot use src_base 
   becasue it was reset by the included file. So I am forced to use 
   src_root now which will hurt especially sore when I include from 
   sub-directories.



DEPENDENCIES : STRUCTURE

@@ It would be nice to be able to chose dependency type project-wise 
   and on a by-makefile basis. This could be tricky, however.

@@ Missing headers assumed generated with some inflexible logic (cur dir).
   This can also vary among compilers (which is not something I would worry
   too much as long as g++ works). Can I make it more reliable? Maybe capture
   this (or essential) dependecies in a Makefile?

@@ Can I specify dependencies in CORBA projects manually. Do I want to do 
   that?

@@ Don't include dependecies when cleaning (configuring?).



MISC

@@ If I have generated idl files in src directory then build in some other 
   directory will fail or will use wrong headers.

%% .NOT_DEFAULT: target in make?

%@ configuration targets should not be parallel. try make -j 4 Maybe I can
   detect that those files do not exist and disable parallelism for this
   run. See .MUTEX bug (#3656).

@@ relative paths and pattern matching does not work very well together