List:Commits« Previous MessageNext Message »
From:Joerg Bruehe Date:January 31 2011 9:21pm
Subject:Re: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969
View as plain text  
Wlad,


you have been extremely helpful:

Vladislav Vaintroub wrote:
> 
>> -----Original Message-----
>> From: Joerg Bruehe [mailto:joerg.bruehe@stripped]
>> Sent: Montag, 31. Januar 2011 18:44
>> To: Vladislav Vaintroub
>> Cc: commits@stripped
>> Subject: Re: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969
>>
>> [[...]]
>>
>> I don't have any issues with those specific "*.exe" file names written,
> Those probably need to be marked as "advanced" so they do not appear here.
> MARK_AS_ADVANCED(CANDLE_EXECUTABLE  HEAT_EXECUTABLE  LIGHT_EXECUTABLE)
> might help here (or maybe even prepend them with FORCE, like
>  MARK_AS_ADVANCED(FORCE  CANDLE_EXECUTABLE ... )

Ok, I'll leave that for later polishing, to be decided by the colleagues
using Windows.

> 
>> but I do miss the timestamp and the "generator" output.
> 
> How do you produce the timestamp? cmd /c date /T worked fine for me (I wrote about it
> earlier)  but not the "date /T",  which in my
> environment called gnuwin32 date.exe , which has no idea of /T

Yes, that is what you had proposed - and obviously I didn't pay enough
attention to really copy what you had written. Done now, to be tested.

> 
> ${CMAKE_GENERATOR} is an internal variable,  e.g more advanced than "advanced",
> it cannot be changed after it is set, one needs to remove the whole build directory
> and rerun cmake in this case.
> 
> But it is available at cmake time, always. If you need it in the configured script,
> usual trick SET(CMAKE_GENERATOR
> "@CMAKE_GENERATOR@") 
> does the trick.

Yes, once I realize this is the cmake way of working, I also understand
I should have added that line. I did it now.

> 
> 
>> Also, I'm a bit disappointed that neither on Windows nor on Linux I get
>> informed whether this was a 32 or 64 bit build, but so be it.
> 
> CMAKE_SIZEOF_VOIDP is the size of void pointer in bytes. It does not have a meaning
> in "mixed bitness" builds, as in osx universal
> binaries.

Ok, I added that also. A first attempt failed, but reading helped:
"CMAKE_SIZEOF_VOID_P" does it.
My original hope had been for a C[XX]FLAG in my Unix tests, but this
variable will be even better readable.

> 
>> This is the code I used (with remarks inserted):
>>
>> | MACRO(CREATE_INFO_BIN)
>> |   [[...]]
>> |   IF(${CMAKE_HOST_SYSTEM})
>> |     IF(${CMAKE_CROSSCOMPILING})
>> |       FILE(APPEND ${INFO_BIN} "Build was done for ${CMAKE_SYSTEM}
>> using ${CMAKE_SYSTEM_PROCESSOR}\n")
>> |     ENDIF()
>> |     FILE(APPEND ${INFO_BIN} "Build was done on  ${CMAKE_HOST_SYSTEM}
>> using ${CMAKE_HOST_SYSTEM_PROCESSOR}\n\n")
>> |   ENDIF()
>> I may replace the above code by two separate "if", for "cmake_system"
>> and "cmake_host_system", but according to the docs I should get output
>> (no crosscompiling, so the values are identical, and only the second
>> line should appear).
> 
> No idea. Personally, I did not find CMAKE_HOST_SYSTEM interesting. Even if MySQL had 
> working cross-compiling environment (which is
> not that simple, because some tools produced during  the build, are also used during 
> the build), even then  HOST_SYSTEM is , from
> my perspective,  would be of limited use.

I agree we need not (yet) worry about cross-compiling, my main interest
is about the platform a package was compiled for.
So either of "cmake_system" and "cmake_host_system" should be fine, my
only reason to output both (guarded by "if cross-compiling") was to be
prepared for the moment this gets added.
I'll keep that code in, so that we profit from it the moment it is
supported.

> 
>> |
>> |   # ${CMAKE_VERSION} doesn't work in 2.6.0, use the separate components.
>> |   FILE(APPEND ${INFO_BIN} "Build was done using cmake
>> ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${CMAKE_PATCH_VERSION} \n\n")
>> |
>> |   IF (WIN32)
>> |     FILE(APPEND ${INFO_BIN} "===== Compiler / generator used: =====\n")
>> |     FILE(APPEND ${INFO_BIN} ${CMAKE_GENERATOR} "\n\n")
>> Also empty in the generated file.
> 
> I think 
> SET(CMAKE_GENERATOR "@CMAKE_GENERATOR@")  at the start of file will help.

I added, and the next test run on a Windows box will show the result.
But I'm very optimistic, my mind simply hasn't got used to the
distinction between "@" and "$" variables yet.


A (hopefully) last test is running now.


Regards and thanks,
Jörg

-- 
Joerg Bruehe,  MySQL Build Team,  joerg.bruehe@stripped
               (+49 30) 417 01 487
ORACLE Deutschland B.V. & Co. KG,   Komturstrasse 18a,   D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven
Amtsgericht Muenchen: HRA 95603

Thread
bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969Joerg Bruehe21 Jan
  • RE: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969Vladislav Vaintroub21 Jan
    • Re: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969Joerg Bruehe22 Jan
      • RE: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969Vladislav Vaintroub22 Jan
        • RE: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969Vladislav Vaintroub22 Jan
          • Re: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969Joerg Bruehe31 Jan
            • RE: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969Vladislav Vaintroub31 Jan
              • Re: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969Joerg Bruehe31 Jan
        • Re: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969Joerg Bruehe25 Jan
          • Re: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969Joerg Bruehe26 Jan
          • RE: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969Vladislav Vaintroub26 Jan