[CMake] Is there really any cmake support?

[Fred Fred]

> Subject: Re: [CMake] Is there really any cmake support?
> From: themiwi at gmail.com
> Date: Sun, 28 Mar 2010 13:10:17 +0200
> CC: stan1313 at hotmail.fr; cmake at cmake.org
> To: eric.noulard at gmail.com
> 
> 
> On 28. Mar, 2010, at 12:37 , Eric Noulard wrote:
> 
> > 2010/3/28 Fred Fred <stan1313 at hotmail.fr>:
> >> This list seems not to be really active
> > 
> > You are kidding right?
> > Did you check the past 3 years archive ?
> 
> Two years worth of messages in my mailbox: 16422...

Ok, I just start on this mailing list but since I did not see much activity, I really wonder what is about it, that's all.
The oter reason is that, concerning the mentionned bug, any response to the problem.
An answer such as "ok, we are aware of it but we have more important priorities now" would have been clear enough. I understand that cmake developpers cannot solve all of the problems arising with their code.

> >> and I did not receive any help since I posted this one week ago.
> >> BTW this issue has been open on Mantis more than
> >> 3 months ago and seems still to be open!
> > 
> > I'm sure that you may find far older bugs on many project.
> 
> And this one is probably one of the harder bugs to fix, and very few people seem to be affected by it (that is, most programmers probably don't even try to use international characters in their path names...)
> 
> > 
> >> So is there really anybody trying to help on cmake??
> > 
> > May be you want :-) ?
> 
> That's how it usually works (and quite well at that) in open source projects: Everybody scratches his own itch ;-)

lol

> > 
> > I think you may be wrong about what to expect from an Open Source
> > community and how to ask for help.
> 
> AFAIK Kitware does prioritize paid work, so perhaps the OP should contact the sales department ;-)
> 
> Back to the original problem:
> 
> The easy fix? Only use ASCII characters in your path names...

As far as I am concerned, I did: I created a specific path, starting from /Development, without any space nor international character, just ASCII ones.
But same issue: the test program testCCompiler.c is never created

> The real fix would be to port CMake to fully support UTF-16/32: a huge undertaking, with any software. Especially, since wchar_t is not guaranteed to be large enough to hold unicode characters; it may be as small as 8 bit! On many platforms, most compilers use 32 bit, but you can't rely on that. The upcoming C++ standard (C++0x) does define exact-width character types (char16_t, char32_t) and the corresponding string types (std::u16string and std::u32string), but then I don't know about the whole machinery you need to actually deal with such strings effectively. However, this is a future standard and I'm very sure that the CMake-developers will not rely on any of its features for years to come since they want CMake to build on all kinds of old and weird systems.

What I do not understand is why would cmake use non ASCII characters? Since my path is in ASCII (at least I hope that a mkdir command with non-accentuated characters does not generate non ASCII paths!) and I checked all the paths in the cmake configuration editor, I do not understand where a problem may arise.

> One option would be to use ICU (http://icu-project.org), but again, this would require a lot of work and is a HUGE dependency...
> 
> Michael

Thx for your answer.

 		 	   		  
_________________________________________________________________
Découvrez comment SURFER DISCRETEMENT sur un site de rencontres !
http://clk.atdmt.com/FRM/go/206608211/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100328/5e967372/attachment.htm>