On 04/05/2010 03:00 PM, Alan W. Irwin wrote:
On 2010-04-05 13:04-0600 Clinton Stimpson wrote:
On Apr 5, 2010, at 11:50 AM, Bill Hoffman wrote:
Alan W. Irwin wrote:
Have you run cmake --trace yet to figure out what is including
what and where?
Yes, as alluded to above
the complete result for cmake --trace --debug-output for
a CMakeLists.txt file consisting of just
project(test NONE)
enable_language(CXX)
was attached to my first post in this thread. Part way through is
starts
accessing CMakeFortranInformation.cmake which is the source of the
trouble.
For your convenience I will attach that cmake output to this post
as well.
OK, you are going to have to look at the C++ code to figure this out.
You will need to add some debug prints to this function:
void
cmGlobalGenerator::EnableLanguage(std::vector<std::string>const&
languages,
cmMakefile *mf, bool)
...
for(std::vector<std::string>::const_iterator l = languages.begin();
l != languages.end(); ++l)
{
Seems that Fortran is getting into the list of enabled languages.
Might also want to put prints in cmEnableLanguageCommand
::InitialPass and void
cmMakefile::EnableLanguage(std::vector<std::string> const & lang,
bool optional)
So interleaving wine tracing and cmake tracing along with some
debugging... the problem comes from within
SystemTools::GetActualCaseForPath() where it takes as input
<somepath>/CMakeTestCXXCompiler.cmake and returns
<somepath>/CMakeFortranInformation.cmake. I'm guessing its a bug in
Wine's
GetShortPathName() or GetLongPathName(). There are more modern apis for
getting the actual case of a file, but they probably don't work on
Windows
98.
Hi Clint:
Thanks for debugging it this far. I (obviously) wasn't looking forward
to setting that up for myself.
From the code itself in kwsys/SystemTools.cxx it just simply returns
what is
input for the non-Windows case. So is the input you referred to above
actually <somepath>/CMakeCXXInformation.cmake rather than
<somepath>/CMakeTestCXXCompiler.cmake? If you actually reporyed that
input
correctly it sounds like SystemTools::GetActualCaseForPath() is
"remembering" values from a previous call which might be an issue in the
CMake C++ code itself when something else is going wrong (say on the Wine
side).
Also, could you look further to see why "project(test CXX)" generates
this
error while "project(test C)" does not? Assuming "project(test C)"
does use
this code path, why are correct results being returned in that case
but not
for CXX?
I've submitted a bug report to the wine bugzilla with a very simple test
case (bug #22286). So the bug can be taken care of or discussed over there.
If anyone needs a workaround until its fixed, just modify
kwsys/SystemTools.cxx's PortableGetLongPathName() to use
OldWindowsGetLongPath() instead of GetLongPathNameA() from kernel32.dll.
Clint
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake