<HTML><HEAD> <META http-equiv=Content-Type content='text/html; charset=windows-1252'> <title>Samsung Enterprise Portal mySingle</title> <style> P, td, li {font-family:Arial, arial; font-size:9pt; margin-top:5px;margin-bottom:5px;} body{font-family:Arial, arial; font-size:9pt;}</style> </HEAD><BODY>For me, a significant benefit is that the cmake build system is much easier to understand and work on, and being faster at the same time. So maybe we'll have less chance of mails like <a href="http://lists.freedesktop.org/archives/xorg/2007-September/027829.html" target="_blank">http://lists.freedesktop.org/archives/xorg/2007-September/027829.html</a> I don't mean that it is "required" or a big benefit to shift to cmake. But the question is, that if someone does the work of proof of concept, is it welcome and going to be accepted (as a "parallel" build system)? > Right. At the moment, I'm not talking about linking static libraries > into shared objects (Debian people tend to have a better appreciation > than most of the problems inherent here), nor am I talking about > shipping static libraries. I'm talking about the convenince libraries > (of which there are over 112) in the server, which are compiled once, > never installed, and then linked multiple times into every server[0]. As Jose mentioned, there is no problem with linking libraries to make executables. We don't need convenience libraries for that, static libraries would be fine. -kamal </BODY></HTML>