On 10/10/07, Piotr Obrzut <[EMAIL PROTECTED]> wrote: > It claims that cs version is < 1.1: > configure:12865: result: no > configure:13099: checking for cs-config-1.1 > configure:13132: result: no > configure:13099: checking for cs-config-1.3 > configure:13117: found \programowanie\cs/cs-config-1.3 > configure:13129: result: \programowanie\cs/cs-config-1.3 > configure:13272: checking if Crystal Space version >= 1.1 > configure:13353: result: no > and it is 1.3 version
I don't have a good answer for you. In my own local tests on Linux, this works correctly. My best suggestion is to wrap shell directives 'set -x' and 'set +x' (in that order) around the invocation of CS_CHECK_PROG_VERSION() in the local mk/autoconf/crystal.m4 file used when generating that configure script and try to trace the printed shell diagnostic to see what is going wrong. (Of course, regenerate configure after making that change in crystal.m4 or edit configure directly.) The backslashes in the pathnames also seem highly suspicious. It may be the case that the shell is interpreting those as "escape" tokens rather than path delimiters, in which case it would fail. We may need to run those paths through CS_PATH_NORMALIZE() or CS_RUN_PATH_NORMALIZE() from CS/mk/autoconf/path.m4. -- ES ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[EMAIL PROTECTED]
