Re: Re: FindSDL.cmake and mingw / msys

> Maybe this could be implemented in a major release of CMake, thus
> developers would be aware that changes are required to their scripts.
> As soon as it is advertized enought, it's ok.

I'm more inclined to leave the current behavior, and when SDL 1.3
finally rolls around, try a fresh start then since we'll most likely
need a new script for that anyway.

> Currenly, under Windows, when I click on the configure button in CMAKE, it
> says:
>
> - I did not found "qmake.exe",
> - so I set the value for the QMAKE_EXECUTABE variable,
> - click on configure one more time.

So we have nothing to do with QMake. Whatever happens there is outside
our domain.

 > - It says, "I did not found SDLMAIN_INCLUDE, SDLMAIN_LIBRARY,
> SDLIMAGE_INCLUDE, SDLIMAGE_LIBRARY"
> - I set those variables,
> - click on configure one more time.
>

So I need more details about how CMake does this. I don't understand
how CMake determines which ones to nag you about. The nags I get are
different than yours.

> And what about calling that variable SDL_LIBRARY_DIR (with
> for example the value "c:\My project\lib") and deducing from

Accessing targets at test time on MSVC

Hi,

I have a situation where I want to add a test that runs a target built
in another directory - so I used GET_TARGET_PROPERTY to get the
LOCATION property of the target, and it works fine with non MS build
systems.
However, with VS6, building the RUN_TESTS project gives the following error:
CMake Error: config type specified on the command line, but test
executable not found.c:/build/TestRun/testtool/$(IntDir)/testtool.exe/Debug/testtool.exe
Unable to find executable: c:/build/TestRun/testtool/$(IntDir)/testtool.exe

This appears to be because the LOCATION property is rendered into the
DartTestFile.txt with $(IntDir) to represent the configuration type.
If I manually change it to ${IntDir} it correctly locates the exe.

Is this a bug?  Or should I be using a different approach?

Here's a minimal example project that demonstrates what I'm doing:

==== Top level CMakeLists.txt ====
PROJECT(TestRun C)
INCLUDE(CTest)
ADD_SUBDIRECTORY(testtool)
GET_TARGET_PROPERTY(tt testtool LOCATION)
ADD_TEST(testtool_test ${tt} foo bar)

==== testtool/CMakeLists.txt ====
ADD_EXECUTABLE(testtool testtool.c)

==== testtool/testtool.c ====

With gcc is __FILE__ with full path. Is there a workaround?

Hello,
another effect. In the past I compiled projects with gcc in the actual 
directory, the source file was "mysource.c". But with the generated cmake 
Makefile it is "/home/mareb/sb/cp/bkupserver/src/mysource.c". 
Into Logfiles I write for example with syslog(LOG_INFO, "%s: abcdef", 
__FILE__) and I do not like the long path.

Is there a way to go the following way?
1) change to source dir
2) call then gcc with source file without path
3) [may return to project dir.]

Or the possible easier way:
1) use relative paths from working (project) directory

Manfred

CMAKE_BUILD_TYPE does not work correctly for Linux and CMake-2.4.6

I have found two bugs in compiler flag support for Linux that I would like
to discuss here before making formal bug reports.

1.  A general compiler flag bug with ENABLE_LANGUAGE.

By accident while investigating the second fortran-related compiler flag bug
below, I also happened an ENABLE_LANGUAGE bug that affects all languages.

The combination

PROJECT(free_eos CXX)
ENABLE_LANGUAGE(C)

defines the correct CXX flags, but blanks the C flags in the cache rather
than defining them properly, e.g.,

//C compiler.
CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc

//Flags for C compiler.
CMAKE_C_FLAGS:STRING=' '

//Flags used by the compiler during debug builds.
CMAKE_C_FLAGS_DEBUG:STRING=

//Flags used by the compiler during release minsize builds.
CMAKE_C_FLAGS_MINSIZEREL:STRING=

//Flags used by the compiler during release builds (/MD /Ob1 /Oi
// /Ot /Oy /Gs will produce slightly less optimized but smaller

Re: With gcc is __FILE__ with full path. Is there a workaround?

Manfred Rebentisch wrote:
> Hello,
> another effect. In the past I compiled projects with gcc in the actual 
> directory, the source file was "mysource.c". But with the generated cmake 
> Makefile it is "/home/mareb/sb/cp/bkupserver/src/mysource.c". 
> Into Logfiles I write for example with syslog(LOG_INFO, "%s: abcdef", 
> __FILE__) and I do not like the long path.
> 
> Is there a way to go the following way?
> 1) change to source dir
> 2) call then gcc with source file without path
> 3) [may return to project dir.]
> 
> Or the possible easier way:
> 1) use relative paths from working (project) directory

what about using basename()?

Filipe Sousa

_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake

Visual C++ 2005: Precompiled headers patch + STATIC_LIBRARY_FLAGS support for .lib type projects

Hello CMake crew,

      someone might find this useful. :)

Index: P:/Elasticity_tools_and_libs/cmake-2.4.6/Source/cmLocalVisualStudio7Generator.cxx
===================================================================
--- P:/Elasticity_tools_and_libs/cmake-2.4.6/Source/cmLocalVisualStudio7Generator.cxx  
(revision 16)
+++ P:/Elasticity_tools_and_libs/cmake-2.4.6/Source/cmLocalVisualStudio7Generator.cxx  
(working copy)
 <at>  <at>  -294,6 +294,8  <at>  <at> 
 cmVS7FlagTable cmLocalVisualStudio7GeneratorFlagTable[] =
 {
   // option flags (some flags map to the same option)
+  {"UsePrecompiledHeader", "Yc", "Create Precompiled Header",             "1"},
+  {"UsePrecompiledHeader", "Yu", "Use Precompiled Header",                "2"},
   {"BasicRuntimeChecks", "GZ", "Stack frame checks",                      "1"},
   {"BasicRuntimeChecks", "RTCsu", "Both stack and uninitialized checks", "3"},
   {"BasicRuntimeChecks", "RTCs", "Stack frame checks",                    "1"},
 <at>  <at>  -746,10 +748,14  <at>  <at> 
       "$(OutDir)/" + targetFullName;
     fout << "\t\t\t<Tool\n"
          << "\t\t\t\tName=\"VCLibrarianTool\"\n";
-    if(const char* libflags = target.GetProperty("STATIC_LIBRARY_FLAGS"))
-      {
-      fout << "\t\t\t\tAdditionalOptions=\"" << libflags << "\"\n";
-      }
+       const char* libflags = target.GetProperty("STATIC_LIBRARY_FLAGS");
+       std::string additionalOptions = extraLinkOptions;
+       if( libflags != NULL )

Re: CMake test suite - 51% failure rate?! (x86/Solaris 10)

Matthew Woehlke wrote:
> [It] turns out g++ is broken, at least in that binaries 
> it produces all have this problem. Which means I seem to have found a 
> "bug"; tests that involve compiling C++ programs either a: ignore that I 
> was using CC=cc CXX=CC to build cmake, or b: fail to notice that g++ 
> produces broken executables. (I'm attaching the full output of 
> 'VERBOSE=1 bin/ctest -V -I 63,63'.)

Any comments? Shouldn't CMake reject g++ if the binaries it produces 
cannot run?

--

-- 
Matthew
Vs lbh pna ernq guvf jvgubhg fbsgjner, lbh ner n FREVBHF areq! -- 
Nqncgrq sebz Znggurj Jva (ivz-qri znvyvat yvfg)

Re: With gcc is __FILE__ with full path. Is there a workaround?

Thank you Filipe,

Am Sonntag, 1. April 2007 23:20 schrieb Filipe Sousa:
>
> what about using basename()?
>
I do use a Macro:

#define CP_PREFIX(varname, functionname)      \
	static const char* varname  = __FILE__ ":" functionname

and use it:

int func(void)
{
   CP_PREFIX(prefix, "func");
   return printf("%s: error msg x\n", prefix);
}

The line with return and printf is only the example of use. I use other 
functions.
With this macro you cannot use a function.

Another idea?

Manfred

Re: With gcc is __FILE__ with full path. Is there a workaround?

2007/4/2, Manfred Rebentisch <mrebentisch@...>:
> Thank you Filipe,
>
> Am Sonntag, 1. April 2007 23:20 schrieb Filipe Sousa:
> >
> > what about using basename()?
> >
> I do use a Macro:
>
> #define CP_PREFIX(varname, functionname)      \
>         static const char* varname  = __FILE__ ":" functionname
>
> and use it:
>
> int func(void)
> {
>    CP_PREFIX(prefix, "func");
>    return printf("%s: error msg x\n", prefix);
> }
>
> The line with return and printf is only the example of use. I use other
> functions.
> With this macro you cannot use a function.
>
> Another idea?

May be.

May be you can use predefined
 C99  __func__ or GCC specific __FUNCTION__ macros

Re: With gcc is __FILE__ with full path. Is there a workaround?

Eric Noulard wrote:
> 2007/4/2, Manfred Rebentisch <mrebentisch@...>:
> 
> May be.
> 
> May be you can use predefined
>  C99  __func__ or GCC specific __FUNCTION__ macros
> and then you should be able to use:
> 
> printf("%s:%s error msg x\n", basename(__FILE__), __FUNCTION__);
> 
> nevertheless my man page says that basename could modify
> its argument which may gives you unexpected result in this case...

 <at> google:
#define FILE ((strrchr(__FILE__, '/') ? : __FILE__- 1) + 1)

Filipe Sousa

_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake