The is no problem using GLOB with a wildcard, as I mentioned at least times in this thread ;)
But explicitly listing each file seems recommended, I forgot why. Perhaps GLOB needs to search for (potential) new headerfiles, every time you build and a .cpp changed (slowing down things unnecesarily)? Perhaps reading the docs, using google or asking on the cmake mailingslist will tell why GLOB can better be avoided in CMakeLists.txt? Cheers, Erwin Sent from my iPhone On Jan 11, 2010, at 3:13, Brecht Van Lommel <bre...@blender.org> wrote: > When I generate an MSVC project with CMake, the header files are in > the project, dependencies seem to be taken into account correctly, > wildcards are used to automatically add/remove files, .. is there an > actual problem here? > > Brecht. > > On Sun, Jan 10, 2010 at 10:53 PM, Erwin Coumans <erwin.coum...@gmail.com > > wrote: >> You can avoid the work by adding a GLOB * wildcard for header files, >> but explicitly specifying every individual file seems recommended >> indeed. >> >> Once you have the cmake project up and running, you usually only >> add a few >> .cpp or .h files at a time, >> so the incremental effort usually isn't much. >> >> This doesn't seem to be a good reason to favor scons over cmake. >> Thanks, >> Erwin >> >> >> 2010/1/10 joe <joe...@gmail.com> >> >>> Yeek. That's horrible. I wonder how hard would it be to write some >>> utility code for the cmakefiles that scans for #include statements. >>> This sort of thing is exactly why I stick with scons, despite it's >>> horrific speed problems. :-/ I'm even tempted to rewrite our scons >>> files to use waf instead sometimes. >>> >>> Joe > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
