On Thu, Jul 03, 2008 at 03:16:34AM +0200, Carl-Daniel Hailfinger wrote:
How do you feel about configure?
Well, the configure scripts i've seen in the past are completely unreadable hideous blobs.
Yeah, they're generated by autoconf, from a pretty readable configure.in file.
Just to be clear, I am not advocating autoconf+automake. I don't think we need that.
Sourcing the requirement checks out to another script is OK, though, as long as that script is human readable and short.
Great, that's the plan.
However, that leads me to the question why we don't want to keep it inside the makefile.
I think Makefile should deal only with the internal dependency graph.
I haven't seen a single Makefile that tries to tie into package management before (outside ports, where they _are_ the package management, well sort-of anyway :) and for good reason I believe.
System variations are too large for this to be handled in Makefile. I think Makefile must assume ideal circumstances, and let the plumbing (compiler, linker, install, etc) report error conditions as they are encountered, lest Makefile becomes like those configure scripts.
Another example would be that it does not make much sense to first check if we have permission to write to $prefix before actually executing /usr/bin/install in the install: target.
On Thu, Jul 03, 2008 at 01:48:33AM -0400, Corey Osgood wrote:
At the very least the message is not clear enough.
I've seen this too, where I had a compiler installed but forgot to set CC or link it to gcc or some such thing. Wouldn't the more correct workaround be to do a compiler check?
Yes, that's what I'm thinking too. I am pieceing something together with parts of coresystems' xcompile script. :)
//Peter