> On Apr 13, 2019, at 9:17 AM, Maria Matějka <jan.mate...@nic.cz> wrote: > > If you convince me to merge it, no problem. Which is more dangerous that it > seems to be -- I'm quite a strong opponent against almost any generator of > makefiles. What I accept is how it is done now – the configure script > generates only a little part of one of the Makefiles, all others being > autoincluded.
Thanks, challenge made. I’ll see if I can come up with something that works, and then others like. It’s a process, I just didn’t want to put much effort in if it wasn’t even an option. If I get there and you and the team like it, we’ll take it from there. > One of the main reasons is simply that it adds another layer of indirection > which should have really good reasons. I wasn’t aware that CMake was a makefile generator, I thought it did everything natively. TIL. The good reasons will hopefully be IDE compatibility… > BTW almost any IDE I know about has an option to set what to run to rebuild > so I don't understand much what about IDE compatibility should improve with > conversion to CMake. … but this part may be the subjective. The last 20 years of my own experience are working in IDEs that have full semantics and pup-up menus accessible through a modifier-click sequence. To say I am dependent on them is an analog to say I am dependent on a chain saw in a secluded cabin. It would be much nicer than cutting wood by hand, but if I am going to die because I have no gasoline for the saw, I would certainly get on with the manual saw… :-) In many cases, it’s sufficient to do a build and then load the directory of built sources. Generated source out of something like bison or flex would then be parsed as normal. But for some reason, it’s not doing that with the BIRD tree. So this inquiry was really about whether I would be the only consumer of the CMake results or there was potentially a bigger audience. best, Brian
