[CMake] Patch to apply! Changing the default name "CMakeLists.txt"! Introduction to "Common Build System"

[Martin Lutken]

On Tuesday 15 January 2008 16:40, you wrote:
> Martin Lutken wrote:
> > That might work too.
> > I also does not understand why You are soo resistant to a minor feature
> > which couldn't really hurt anyone?
>
> I just want to make sure it is a feature that we want.  I will be one of
> the ones supporting it for as long as CMake is around.  As it is your
> patch has some issues.   For example, if you changed a CMakeLists.txt
> file, and ran make on the build tree, it would fail as it is.  This is
> because the command to rerun cmake would also need to have the -f flag
> as well, and does not. Of course, that can be fixed.
>
> So, I guess the process for getting stuff into CMake should be stated
> somewhere.  So, here it is:
>
> 1. Have the idea approved on the cmake mailing list.  Basically get buy
> in from the CMake community and developers for the feature.
>
> 2. Create a bug / feature request in the bug tracker.
>
> 3. Submit a patch to the bug tracker, complete with a test case that has
> good coverage on the new code being added.
>
> (3 is optional, but should speed things up.  If it is a must have
> feature, then the cmake developers will eventually get around to adding
> it.   However, it it is a solid well tested patch, it will more more
> likely to be added as-is.)
>
> My concerns for this feature are as follows:
>
> It will confuse users of CMake.   They will download a project and have
> to use extra command line arguments to get things to work.  If they just
> run CMakeSetup, cmake, or ccmake as stated in the usual CMake
> documentation it will not work.  Basically, I think it may make cmake
> based builds harder to understand and support.
>
> I would think that the existence of two complete cmake build systems in
> any one source tree, would be one two many.  It is hard enough to
> maintain one build system, much less two flavors of cmake.  Seems like
> something that would only be used as a temporary stop gap.  The new
> build stuff would either be accepted or rejected by the project, and the
> co-existing stuff would go away.  For a temporary thing, it could be
> done with includes, and parallel source trees.
>
> I don't mean to offend, and I appreciate your use and extensions to
> CMake, and look forward to your future contributions.
>
> -Bill

Hmm well I see .... It can wait anyway.
I allready do the include-trick from the general Makefile, but in the 
transitional phase for a large project it would be much easier to be able do 
it that way.
Maybe it's because I never really used CMake GUI frontends.... Only tried them 
briefly. Since I am trying to construct a system in which you can build and 
configure many (possibly a complete Linux Distribution) in one build, while 
still workinbg perfectly for the individual subprojects I have neeeds which 
are a bit special ....
But I might add the request to the feature request list...

-Martin