Bill Hoffman wrote: > Maik Beckmann wrote: >> Hello CMake people >> >> I pushed myself during the last weekends to get more familiar with >> CMakes codebase. Not for fun only ;), but make me smart enough to >> sketch an approach for handling fortrans module dependencies. >> >> Bill, Brad, Alex ... it would be very nice if you're take a look at >> - >> http://www.cmake.org/Wiki/CMake_Fortran_Issues#Introduction_to_the_problem >> >> - http://www.cmake.org/Wiki/CMake_Fortran_Issues#Abstract_solution >> - http://www.cmake.org/Wiki/CMake_Fortran_Issues#Concrete_solution >> >> I did some wild proof of concept coding, but its not ready be shown so >> far. (see the class definitions at >> http://www.cmake.org/Wiki/CMake_Fortran_Issues#Concrete_solution) >> >> Howevery, the process of >> - parsing sources and make the information persistent >> -> -E fortran_module_scan >> - reload the information and generate depend.make >> -> -E cmake_depends using the persistent information >> works for a simple exe-target with an arbitrary number of sources >> involving modules. The next thing is to handle modules provided by >> another target in the sourcetree. >> >> For convenience I'm temporary using boost.serialization for the >> persistent part. If the hole thing is in shape I will work cmakeish >> solution. >> >> The hardest thing for me is to decide how to alter the way Makefile(2) >> is generated i.e. where to trigger the module extraction. Some advice >> on this would be very helpfull. >> >> I will do best to apply your advises. ASAP I will provide a patch to >> make this issue less abstract. > > Brad is actually working on fortran support right now.
This is correct. I'll add some comments to the wiki. -Brad _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake