<font size="2"><font face="tahoma,sans-serif">Hi;<br></font></font><br><div class="gmail_quote">On Thu, May 19, 2011 at 6:28 PM, Óscar Fuentes <span dir="ltr"><<a href="mailto:ofv@wanadoo.es">ofv@wanadoo.es</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">İsmail Dönmez <<a href="mailto:ismail@namtrac.org">ismail@namtrac.org</a>> writes:<br>
<br>
> Thanks, my one other big complaint with cmake is that it produces:<br>
><br>
> liblibclang.a<br>
> liblibclang.so.3.0<br>
><br>
> It might be OK on Windos but this is really wrong on Linux and other Unix<br>
> variants, shouldn't this be done only for Windows port if at all?<br>
<br>
</div>Then users maintaining cross-platform projects would need to<br>
discriminate the library name by toolchain, which is not very<br>
friendly. I'm supposing that most people use either cmake or<br>
configure&make for their client projects, not both.<br></blockquote><div><br>Well this rules out using cmake on Linux because liblibclang.so is wrong from shared lib perspective.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


The name liblibclang is forced by an unfortunate collision between MS<br>
and GNU name conventions. We can't create clang.dll with MS since we<br>
already have clang.exe on the same directory (.pdb, .ilk and possibly<br>
other files collide) so we must use some other name for clang.dll, like<br>
libclang.dll. Then this produces liblibclang.so on GNU.<br></blockquote><div><br>Well there is no need to for this on !Windows platforms imho.<br><br>Regards,<br>ismail<br><br></div></div>