When it was first created, I checked it and it didn't work for me, but I didn't have the time to find out why and had a crisis on another project.
Try again ... It works this time. I think the failure the first time had something to do with stuff hanging around from before, but I cannot reproduce the failure, so I think it works. My original intent was to put back autoconf when it works, but still keep the "old" system as an alternative. I would like to be able to offer Cmake too. One side of me wants to develop the "old" system into a full system. A more practical side of me says that I don't have time to do this. I still have issues with the complexity and clutter of autotools, which is why don't want to make it the only way. Some thoughts ... 1. Is there a way to hide the clutter? Files like config.guess, depcomp, .... These really shouldn't be up front where they are the first thing people see. Can this stuff be in a subdir "autoconf-generated-files"? 2. It does lots of tests that seem irrelevant, to the extent that if something really is wrong it will often be buried by the clutter. I don't see any place where those tests were requested. It seems that autotools ALWAYS does this, everywhere. It checks for C headers that gnucap doesn't use, and doesn't check for the C++ headers that gnucap does use. What really bothers me about this is that I could not find where such tests were requested. 3. The essense of the "old" system, which predates autoconf and was never intended as a complete system, is a 3-part Makefile, that splits the program specific part (Make1), the requested (generated in this case) configuration (Make2), and a part that is always the same (Make3). An equivalent of "configure" would generate Make2 and cat the 3 parts. Autotools seems to scramble it into an unreadable mess. How about using autotools to generate Make2, and allowing a Make1 to be used without processing? This would allow users to configure the apps, and provide a base for compiling plugins. 4. The file configure.am makes reference to specific external plugins. This is a violation of a basic design goal of the plugin system. 5. Some other programs that use autoconf have managed to tame some of the compile time clutter. Can (should) we do that too? 6. The "gnucap_default_plugins" name change threw me .. caused breakage that I didn't see at first. After finding it, it's so minor I can't really object. That might be why it didn't work the first time. Thanks for doing the work this far. I realize that there isn't really a good alternative yet, so we need to go with it. But we need to go with it in such a way that we are not bound to it. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
