On Mon, 4 Feb 2013 02:45:24 -0800 (PST) Oleksiy Ch wrote: > Taking all the pitfalls of autotools it should be stated that it > covers all imake capabilities plus adds a bunch of new features. Imake > is just static. And this is a big advantage/disadvantage. You look > only at one side - advantage. It's static so it's great for maintainer > that doesn't like things that change. For this case a minimal portable > configure.ac can be crafted that reads *.cf and *.rules and you > get all Imake capabilities plus shell to do tests and all > autotools capabilities. Let's make preset defines for different > OSes that do not change if we select that OS in configure option: > configure --preset-config=OS [openbsd freebsd linux sun ibm hp ..] > >> -send it an OS name that is not expressed the way GNU wants, > >> and good luck having anything build. (config.sub and > >> config.guess, I'm looking at you) > Add option with strictly defined OS names derived from file names > config/cf/*.cf.
If you do that, I guess that covers those arguments. > >> -it claims to test for features, but half the time the tests are along the > >> lines of > > don't use that macro. That's all. Write your own macro, more correct. <snip> > >> -In fact, it frequently ends up dragging in more dependencies on GNU tools > >> (gmake, gm4, bash, and the list goes on) > don't use that macro (which does mean rewriting some macros) > >> And of course, that requires GNU m4 1.4+ "because we need > > just don't use that macro, if I understand you right In this case, I'm talking about regenerating configure. If I remember right, auto* drags in perl and GNU m4 1.4+ as dependencies. > >> Autotools works, except when it doesn't. > Let's make backward compatibility by putting all preset defines in > configure.ac > > All your headache can be resolved by using preset config option. > Think about user. Does he want to read a manual to find out how to switch off > that module in compile time that requires some dep that don't want to > install. > These examples are from my experience as a user building software from source. Fixing auto* when it breaks is worse than reading a manual. > Why do you pass over all features that autotools give? > > Alex My experience is that I can usually build Motif software from the mid-1990s with minimal changes to the Imakefiles. Software from the early 2000s that uses autotools is far harder to get building. And the point is to build the software, not just to provide a configuration infrastructure. Another thing to bear in mind: any old software will need CDE's Imake files installed to build. So getting rid of imake is potentially dangerous for compatability. Now, regarding the patch: Overall, it checks for too much. -ln -s is supported on any vaguely POSIX-like OS. It's only an issue if you want CDE on Windows, without cygwin. -a working libXm implies libXt, libMrm, libUil, libX11, libXaw, and a few others. -Autoconf will mislead people because true Motif is required, and Lesstif will satisfy autoconf. Basically, I'd say it makes sense to check for these libs: -lX11 -lXaw -lXm #check if it has printing, too -lXp #just disable the printing stuff, unless libXm has printing. -lXdmcp # HasXdmAuth -lcrypt -lfl -last # I thought we use an internal version? -lpam -ltcl -lPEX5/-lphigs: No current X11 has these, but probably some older systems do. Are they here by accretion? It seems to me that one could easily write a script that checks for a few tools and libraries,then writes a new site.def (I think that's the file...); in fact, I wrote a script that gets all options for awk, yacc, lex, CXX, CC, and make while checking for install, sed, and rpcgen in 30 lines of POSIX shell. This would allow one to go /configure && make World while not deprecating Imake or getting the disadvantages of autoconf. -- Isaac Dunham ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
