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
