> It is mainly a novice builder/user usability problem; i.e.
> if we need to
> manually enable all features then there should be a
> universal, simple way
> to get a listing of all features that can be enabled. 
> Opening the
> CMakeLists.txt file and reading the entire thing does not
> count. ;-)

I agree that the experience and knowledge of packagers will vary and I'm a good example. :) I'm still learning.

A deeper problem is without a simple way to enable all build options there is no way to test all the features. Each distro is different. Developers and packagers are inclined to test only what applies to their distro. If all build options were enabled as the default, yes, developers and packagers would see immediate build failures because various dependency packages are not installed, etc. That's good for raising awareness. The worst that happens with enabling everything as a default is with each such build "failure" developers and packagers have to disable those build options until they are happy.

Enabling all options as the default helps developers and packagers know what is going on. I don't think ccmake will help the same way the simple option of ./configure --help did. Enabling all build options as the default exposes everything immediately.

Or as Bruce mentions, some kind of stdout of which options are enabled and which are not.

This ties into a point I raised some time ago about quality assurance testing. We are the upstream supply for the Trinity sources. We don't have a quality assurance plan for developers and packagers to follow. When we don't test all the various build options then that reflects on us when others downstream use those options and the build fails. We need a way to test all build options and respective usability features.

An example of this shortfall is the problems people have building KOffice. GraphicsMagick is not a standard package installation in many distros and thus, is not tested by many people. Those who did install that package ran into build problems.

I'm more or less one of the "back breakers" who finds these types of bugs. That is what I do when I test Trinity packages. I enjoy doing that kind of work to help the project. :) I don't mind doing this kind of testing but we need a way to easily enable all build options.

Another thing that seem to commonly break with building packages is not looking in /usr/include subdirectories for header files. To me that should be automatic, whether or not cmake supports that by default.

Once in a blue moon I see this same problem in *.cpp and *.h files where a header include is hard-coded to /usr/include and has no if-then to look for a subdirectory.

Darrell