On 07/19/2013 21:59, Felix Salfelder wrote: >> I still have issues with the complexity and clutter of >> autotools, which is why don't want to make it the only way. > > the more options, the better.
I don't think the clutter should be a big deal; autotools is a mess, but git is good at cleaning up the resulting pile of junk. Users who aren't tracking the sources in git probably aren't going to hang on to the sources after a successful compile/install, anyways. >> 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"? > > until now, i haven't found anything. apparently nobody else cares > since i'm short on time right now, i'd prefer to make it work and change > aesthetic aspects later. Not that I know of; but you can quickly dispose of it with git clean. CMake is nice enough to let you do the build stuff in a separate folder. Speaking of CMake and the resulting build system wars, I think it's important to have around some 'common' build system that a few people here and there have worked with. This makes package/port maintenance a lot easier and gives you a better chance to git the user something he/she knows how to work with. >> 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. Based on my inexpert opinion, I *think* it's worth the while to work on a new build system. The autoconf documentation warns against 'custom' configure/build systems for multiple reasons, you can find it here [1]. > some things are a pain to do with static Makefiles/Cmake/whateverelse. > but that doesn't mean autotools is a requirement. i'd like to focus on > the user, who will never have to mess with the internals. Although I'm certainly biased, I think using a well-known build system makes it easier for users and maintainers. Thanks, Kevin Zheng _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
