On Thu, Dec 17, 2015 at 02:44:19AM -0800, Chris Brannon wrote: > Adam Thompson writes: > > > Definitely, otherwise we leave ourselves open to all sorts of strangeness in the future. > > Well unfortunately checking for Tidy versions is going to be a smidge > more involved than I'd like. Basically at compile time, we can > trivially determine whether we're trying to link against tidy or > tidy-html5, refusing to link against old tidy. > But then we also have to do a runtime check, to make sure that we have a > recent enough tidy-html5. Ok, that makes sense, though I'm surprised we can't check at configure time if the version of tidy defines the symbols (and macros) we expect. I know autotools can do this and I'm sure I've seen someone do something like this with cmake before now. > >> That begs a question. At some point, should we consider deprecating all > >> of our makefiles? > > > I was actually planning to send an email asking this, > > Yes, it works quite well, doesn't it? > I've always been a bit fond of our single makefile approach, but cmake > is so much better for the cross-platform stuff. > If we keep the makefiles around, our biggest concern will be > guaranteeing that they never get out of sync with cmake. I personally like makefiles but they're no use for compiling with native Windows tools (i.e. not MinGW etc). Cmake does all this stuff for us and appears to work well. > > is there any chance we could add an install (and even uninstall) > > rule just to make everything a bit more standard and in case we ever need to > > compile parts of the code as shared objects? > > Sure. I added the install rule tonight. Thanks. > It's too bad that cmake doesn't give you an uninstall rule "for free", > but they describe how to craft one in their FAQ. I'll be happy to add > it if you like. If it's not too much work then yes please add it. Cheers, Adam.