Hi Johannes,
On 02/03/2014 12:57 PM, Johannes Totz wrote: > Hi, > > We are constantly running into a Visual Studio (both '10 and '12) issue > where the compiler crashes with a buffer overflow if the include path > gets too long. The limit seems to be somewhere below 30k characters. > > CMake insisting on using absolute paths for everything does not help. So > our work-around is usually to shorten the path where we store the source > code and build directory on disc. But we are now down to "c:\a" and > still run into this every once in a while. We did run into these issues too. What MITK version are you using? The current master contains a few build-system changes which should lead to shorter include and link directory lists. This is mostly due to specifying the minimum requirements on ITK and VTK modules for modules (ITK and VTK contribute a lot to the overall length. As a side note, I always wondered about the response file support in the CMake Visual Studio generator. Response files should be supported by the NMake generator though. So if you "just" want to get MITK compiled with VC, you could use the "NMake" generator (or probably JOM for prallel builds) which should place the compile and linker commands in response files with which cl.exe is called. Or try out the latest master :-) Another problem is the handling of directory scoped include directories by CMake. Unfortunately, CMake does not / cannot remove duplicate include directories (the new build-system changes tried to remove some duplicates btw) which lead to even longer compile lines for nested modules/targets. > Looking at the include path for an mitk plugin, it's transitively > inherited from all dependencies (other mitk modules, etc), even though > most these are not needed. Well, a library cannot know in advance which headers are needed by a dependent library. Theoretically, we could try to reduce the dependencies by splitting them into "public" and "private" (implementation) dependencies but this would require a lot of work (I would love to see that happen though). This is also connected to the problem that modules usually export too many headers and symbols. > > Do you have any thoughts on reducing the amount of header-dependencies? > Say via forward-declarations? Or good old pimpl? A large part of the > include paths listed are simply there because some mitk header depends > on loads of other stuff. Forward-declarations or pimpl would only help to a certain degree, because for public symbols in forward declarations the include directories still need to be present (otherwise, clients couldn't include the header file declaring that symbol). Hiding implementation details via pimpl and hence maybe reducing public library dependencies is another matter. We frequently discussed that but it is not an easy task. I am also not sure if it would help so much (apart from being a better design) because of the ITK difficulties you mentioned below. Again, this is unfortunately a matter of human resources. > > Forward-declarations for ITK are going to be difficult (and/or ugly) > because of that MyClass::Pointer smart-pointer convention. VTK uses > vtkSmartPointer<MyClass> so would be easier. > > Any plans or thoughts on this? > The first "action item" in my opinion would be to use a newer CMake version and change the MITK build-system to use target scoped include and link directories. Currently, the minimum CMake version required by MITK is 2.8.7 (contained in Ubuntu 12.04 LTS). We need to figure out how to keep users happy if we are going to require the latest CMake. Next would be support for public/private/interface target dependencies. This would require changes in the MITK source code to have a visible effect. Any other ideas, comments on this issue are of course very welcome. Best, Sascha ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
