From: David S. <on...@gm...> - 2012-03-04 08:57:22
|
On Sat, 03 Mar 2012 20:20:25 +0200 Tom Hacohen <to...@st...> wrote: > On 03/03/12 20:10, Vincent Torri wrote: > > > > 1) build systems are for developpers. 99.9% of users don't care > > about build systems as they use the packages of their distro. So > > "people *do* use cmake in the outside world, and shipping does > > could be nice for them" is not a good argument imho. > > I'm sorry for not being clear enough in my previous email, I said > shipping FindEina.cmake and the such would be nice (they are like > pkg-config for cmake) as other developers who write code create their > projects using cmake (me for example?) and it would be easier for them > to do find_pkg(Eina) instead of using the pkg_config wrapping cmake > macros. There is a really large project that I am working on. I did not create this project, but I work on a few forks of it, including one of my own. The company that made it originally have done a good job of creating an ecosystem where forking from their original is common (end sarcasm). It uses cmake. I have added new autofoo built libraries to it, it can be done, but it's obvious to me that cmake is a better choice for adding to this project, as it just meshes in better. So far it seems that wrapping autofoo is easier than converting autofoo to cmake. If there is the option of both, then cmake is the clear winner for this project. I intend to add EFL to this project at some point in the future. I'd be very happy if EFL had even a minimum of cmake support. I wont mention if I think autofoo is better or worse that cmake, I just work with what I got and try to do my best. For what it is worth, in my own projects that I own completely and start from scratch, I have used neither. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. |