On Thursday 22 May 2014, Kevin Zheng wrote: > On 05/22/2014 00:19, al davis wrote: > > Later, when the configure;make protocol caught on, the > > configure script simply generated the appropriate Make2. > > The problem I initially encountered was that `configure` did > not pick up a few settings that I wanted, which meant that I > needed to swoop in and edit Make2 myself. This was also > confusing because I didn't understand the purpose of > Make1/2/3.
At least you could do that, and that is because the system was designed before the autotools or cmake or anything like them existed. Back then, a choice of Make2's covered a lot of systems. I stopped developing it when I thought there was no longer a need, hoping for things like autotools to takeover. In a way, they have, but I find the quality disappointing. > CMake takes a different approach by generating a build > system. You run CMake to produce Makefiles, Visual Studio > projects, etc., and then build the project with those. This > seems more modular to me, especially for systems without > make. It really isn't all that different. My biggest objection to CMake is that it creates another dependency. One important test of a build system is to try to configure and compile on a completely empty system, with nothing but the minimum installed, not even the compiler. The configure system should guide you through the process of installing what you need. As a minimum, it should handle the missing tools and libraries better than just compiling and noticing where the compile fails. Often, this isn't true. After passing that one, the next test is to do a similar test from a student account in a university, where you don't have root and the sysadmin doesn't want to be bothered with your nutty requests. Not saying the "old" system passes this test, but at least the files are editable. > I encourage you to compare 'lib/Make1' with > 'lib/CMakeLists.txt'. For autotools, the equivalent will be > 'lib/Makefile.am'. In my highly-biased opinion, CMake has > the cleanest per-directory Makefile. They are really not much different when you compare in a meaningful way. The extra stuff in Make1 is to do things like the distribution tarball, "make clean" "make distclean" "make rcs" (the old revision control system). You really need to specify that stuff. Leaving it to auto-whims doesn't cut it. The syntax used by CMake may be nicer, but it is not the same as Make, and there is no real reason to depart from Make syntax. If I am rearranging (as to do the split build) I want something that looks like just a simple Makefile, unburdened by the other stuff. The fact that converting to both autotools and CMake is nontrivial, and the fact that the converted files are not smaller and simpler than the original, points out the need to keep the old system. > > Cross compiling ... You really need to build the native > > version and use it to cross-compile. The critical part is > > modelgen, which needs libgnucap. > > > > It may be reasonable to require that to cross compile you > > need to have a native version installed, but then which > > modelgen do you get? > > I'll need to work on cross-compiling. It makes the most sense > to build the native modelgen without using anything that's > pre-installed. Again, I think it is reasonable to expect that to cross-compile you must have a native version installed. Then the difference between "cross" and "native" aside from which compiler and libraries to use is that "cross" would use the installed modelgen and check the headers for compatibility, but "native" would use the modelgen and headers being built. Otherwise, it would really need to build twice, when most likely the native version IS already installed. It could go either way. I am thinking what is easier, because harder may never happen. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
