Fix build with gcc 4.3

(Explanation: 4.3 detects when a local typedef redeclares a templated type
 from an enclosing scope. This was never legal anyway)

.gitignore

@@ -2,6 +2,7 @@
 *~
 *.tar.*
 .[^.]*
+*.o
 *.os
 *.gch
 ,valgrind.log*
@@ -13,5 +14,6 @@ bin/*
 autom4te.cache/*
 scripts/*
 configure
+config.log
 aclocal.m4
 semantic.cache

src/common/meta/configflags.hpp

@@ -107,26 +107,29 @@ namespace lumiera {
             >
     struct ConfigSetFlag<Fl, Config<f1,f2,f3,f4,IGN> >
       {
-        typedef Config<Fl,f1,f2,f3,f4> Config;
+        typedef typelist::Config<Fl,f1,f2,f3,f4> Config;
       };
     
     
     
-    /** build a configuration type for the given list-of-flags */
-    template<class FLAGS, class CONF=Config<> >
-    struct DefineConfigByFlags
+    /** build a configuration type from a list-of-flags */
+    template<class FLAGS, class CONF=typelist::Config<> >
+    struct BuildConfigFromFlags
       {
         typedef CONF Config;
         typedef Config Type;
       };
     template<char Fl, class FLAGS, class CONF>
-    struct DefineConfigByFlags< Node<Flag<Fl>,FLAGS>, CONF>
+    struct BuildConfigFromFlags< Node<Flag<Fl>,FLAGS>, CONF>
       { 
         typedef typename ConfigSetFlag< Fl
-                                      , typename DefineConfigByFlags<FLAGS,CONF>::Config
+                                      , typename BuildConfigFromFlags<FLAGS,CONF>::Config
                                       >::Config Config;
         typedef Config Type;
       };
+    /** create a configuration type for the given list-of-flags */
+    template<class FLAGS>
+    struct DefineConfigByFlags : BuildConfigFromFlags<FLAGS> { };    
     
     
     /** 

src/proc/asset/buildinstruct.hpp

@@ -108,7 +108,15 @@ namespace asset
     : public InstructEntry 
     {
       template<typename T>
-      BuildInstruct (T& instr) : InstructEntry(instr) {}
+      BuildInstruct (T& instr) : InstructEntry() {}
+
+      // TODO: this ctor is *not* correct, just to make it compile
+      // There is a strange problem with boost::variant, probably becausse the
+      // template parameter T could be anything (but actually we know it's one
+      // of our Instruction types.
+      // I have to reinvestigate this design anyway, and probably will replace
+      // the boost::variant by something else, derive from a common base or such.
+      // Note: as of 8/2008 ProcPatt is just a draft and not implemented.
     };
     
     

src/proc/asset/procpatt.cpp

@@ -91,7 +91,8 @@ namespace asset
     else
       {
         DoAttach entry(node, where);
-        instructions_.push_back(BuildInstruct(entry));
+        BuildInstruct instruction(entry);
+        instructions_.push_back(instruction);
       }
     TODO ("declare dependency??");
     return *this;

src/proc/engine/nodewiring.hpp

@@ -37,7 +37,7 @@ namespace engine {
 
   class WiringFactory;
   
-  namespace { class WiringFactoryImpl; }
+  namespace { class WiringFactoryImpl; }  ////TODO: better use a named implementation namespace! (produces warings on gcc 4.3)
   
   
   /**

src/proc/mobject/session/defsregistry.hpp

@@ -52,7 +52,7 @@ namespace mobject
     using boost::lambda::_1;
     using boost::lambda::var;  
     
-    namespace // Implementation details
+    namespace // Implementation details //////////////////TODO better a named implementation namespace (avoids warnings on gcc 4.3)
       {
       struct TableEntry 
         {
@@ -159,7 +159,7 @@ namespace mobject
       template<class TAR>
       size_t Slot<TAR>::index (0);
       
-    }
+    } // (End) impl namespace
     
 
     /**

tests/components/proc/mobject/session/defsregistryimpltest.cpp

@@ -102,8 +102,8 @@ namespace mobject
         {
           scoped_ptr<DefsRegistry> reg_;
           
-          typedef P<Dummy<13> > O;
-          typedef P<Dummy<23> > P;
+          typedef lumiera::P<Dummy<13> > O;
+          typedef lumiera::P<Dummy<23> > P;
           
           typedef Query<Dummy<13> > Q13;
           typedef Query<Dummy<23> > Q23;