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


thank you very much for following up on this.

I had some issues to solve about the build environment first, but now I
can attend to the contents again. I combine your two mails into one and
reply to both:


Vladislav Vaintroub wrote:
> Hi Joerg, 
> now that I tried you patch,  some more comments. I also built a patch based on yours,
>  with couple of things changed/fixed.
> 
> So, the comments:
> 
> 1) You execute VERSION_BIN twice, at cmake time and at build time . At cmake time you
> execute it via inclusion of
> INCLUDE(version_files.cmake), at build time via cmake -P version_files.cmake
> Unfortunately, at cmake time this leads to VERSION_bin in source directory. This is
> best avoided, out-of-source builds treat source
> directory as read-only (at least they should try to be clean. I also think that build
> time is not  the correct time to run those
> scripts. I think the install/package time is the best time, but more on this below.

I agree, it has always disturbed me that too much is done at cmake time,
but I didn't find why this happens.

About install/package time being the best, I disagree:
In my understanding, most of the relevant options which we want logged
are those of compile/link time: compiler and feature flags.
If no flags are changed between build and package time, it doesn't
matter, but if some are changed, I'd rather collect what was valid at
compile time.

So I should search a way to include "cmake/version_files.cmake" (in
order to get the macros defined) but not have this inclusion cause any
execution. I guess this means to not have the "VERSION_BIN" macro call
in the file, but rather have a second file with a similar inclusion and
then this call.

I'll experiment a bit along that line.

> 
> 2) on Windows,
> EXECUTE_PROCESS(COMMAND "date" "/T"  OUTPUT_VARIABLE TMP_DATE)
>  Will not always lead to a good result. You want to run the cmd.exe bultin, however
> if there is a date.exe in the PATH (like in my
> case , from C:\Gnuwin32\bin), date.exe will be taken
> You can force cmd.exe builtin adding  cmd /c to the command, there is no need for
> quotes.
> 
>  EXECUTE_PROCESS(COMMAND cmd /c date /T  OUTPUT_VARIABLE TMP_DATE)

I'll copy that, thanks.

> 
> 3) Executing script at *package/install* time. I believe this is what is appropriate
> in this case, not cmake time neither build time
> (there is no benefit from doing it during cmake or make, the goal is having those
> files in package or after "make install") .

Not necessarily - see above for one reason why I prefer build time.

The other reason is RPMs (or any other format which we might package
ourselves, not using cpack): We need the information about the binary in
these cases as well.

A third reason: We might run a build and then a test, all without
packaging. We should have that information available.

For all these reasons, I prefer to do it at build time.

> 
> [[...]]
> 
> 4) CMAKE_HOST_SYSTEM  variable you mention seem to be crosscompiling related.
>  CMAKE_SYSTEM_NAME, CMAKE_SYSTEM_VERSION and CMAKE_SYSTEM_PROCESSOR is what is used
> everywhere else (e.g in the same top-level
> CMakeLists.txt)

The way I read the documentation, both "CMAKE_HOST_SYSTEM*" and
"CMAKE_SYSTEM*" should be set in any build, and the values will be
different only if cross-compiling. When I tried, neither produced any
output.

> Also , CMake 2.6.0 is really old now, the online documentation reflects the latest
> patch version (for 2.6, it would be 2.6.4 ( May
> 2009), and not  2.6.0 (May 2008))

Cmake 2.6.0 is associated with Debian "stable", that is what I am
running. I may need to install a VM with a newer version, but I am
reluctant to upgrade my base OS.

I am aware that newer cmake versions might do better, especially for
those variables, that's why I left those output lines in the files even
though they don't do anything on my system.

> 
> 
> I allowed myself  to modify your patch (see attachment), the changes are related to
> a)  avoid writing to CMAKE_SOURCE_DIR. I made VERSION_SRC to always write to
> ${CMAKE_BINARY_DIR}/VERSION_src
> b) avoid doing extra stuff during cmake or build stage. Moved generation of
> VERSION_xxx to packaging/install/make_dist stage
> c) fixed Windows date mentioned above
> 
> I did not fix the CMAKE_HOST_SYSTEM though
> 
> Have a look, perhaps you would find it useful.

Yes, I hope to take parts from it - except where I disagree with you as
described above.



Your second mail:

> Hi Joerg,
> 
> Some more feedback (this time only windows-related).
> 
> I get this in VERSION_bin files
> 
> 
> ===== Compiler flags used (from the 'sql/' subdirectory): =====
> File 'sql/CMakeFiles/sql.dir/flags.make' is not yet found.
> 
> Unless  build is done with NMake, there will never be such file.  To extract build
> flags from Visual Studio, you'd need to process
> project files with an XML processor. Maybe, just skipping this for Visual Studio
> would be appropriate.
> For Visual Studio users there relevant info in CMAKE_GENERATOR  variable (Visual
> Studio version) that is worth to be output.

Ok, so I will differ between Unix and Windows in that section.
This will then allow me to use a decent "egrep" call, rather than that
horrible command sequence which inserts line breaks (which IMNSHO cmake
should never have ignored in the first place).

> 
> ===== Feature flags used: =====
> Some info extracted from CMakeCache.txt are internal flags, hidden from user in
> normal cmake-gui or ccmake (stuff with :INTERNAL
> suffixes, like WITH_MYISAM_STORAGE_ENGINE:INTERNAL=ON).
> Some interesting flags on the other hand are missing (like INSTALL_LAYOUT or
> MYSQL_DATADIR). Maybe, cmake -LH ${CMAKE_BINARY_DIR}
> could do a better job in extracting interesting flags.

I trust I won't need the "H" (help) lines in the output. Here is what
"cmake -L ." (in the binary directory) gives me:

 joerg@trift-6core:/MySQL/REPO/V55/bug42969-5.5/try$ cmake -L .
 -- MySQL 5.5.9
 -- Configuring done
 -- Generating done
 -- Build files have been written to: /MySQL/REPO/V55/bug42969-5.5/try
 -- Cache values
 CMAKE_BUILD_TYPE:STRING=RelWithDebInfo
 CMAKE_INSTALL_PREFIX:PATH=/usr/local/mysql
 COMMUNITY_BUILD:BOOL=ON
 ENABLED_PROFILING:BOOL=ON
 ENABLE_DEBUG_SYNC:BOOL=ON
 EXECUTABLE_OUTPUT_PATH:PATH=
 HOSTNAME:STRING=trift-6core
 INSTALL_LAYOUT:STRING=STANDALONE
 LIBRARY_OUTPUT_PATH:PATH=
 MYSQL_DATADIR:PATH=/usr/local/mysql/data
 MYSQL_MAINTAINER_MODE:BOOL=OFF
 WITH_ARCHIVE_STORAGE_ENGINE:BOOL=OFF
 WITH_BLACKHOLE_STORAGE_ENGINE:BOOL=OFF
 WITH_DEBUG:BOOL=OFF
 WITH_EMBEDDED_SERVER:BOOL=OFF
 WITH_EXTRA_CHARSETS:STRING=all
 WITH_FEDERATED_STORAGE_ENGINE:BOOL=OFF
 WITH_INNOBASE_STORAGE_ENGINE:BOOL=ON
 WITH_LIBEDIT:BOOL=ON
 WITH_LIBWRAP:BOOL=OFF
 WITH_PARTITION_STORAGE_ENGINE:BOOL=ON
 WITH_PERFSCHEMA_STORAGE_ENGINE:BOOL=ON
 WITH_PIC:BOOL=OFF
 WITH_READLINE:BOOL=OFF
 WITH_SSL:STRING=no
 WITH_UNIT_TESTS:BOOL=ON
 WITH_VALGRIND:BOOL=OFF
 WITH_ZLIB:STRING=system

In comparison, this is what "grep" extracts for me:

 joerg@trift-6core:/MySQL/REPO/V55/bug42969-5.5/try$ grep '^WITH'
CMakeCache.txt  | sort
 WITH_ARCHIVE_STORAGE_ENGINE:BOOL=OFF
 WITH_ATOMIC_LOCKS-ADVANCED:INTERNAL=1
 WITH_ATOMIC_LOCKS:STRING=
 WITH_BLACKHOLE_STORAGE_ENGINE:BOOL=OFF
 WITH_CSV_STORAGE_ENGINE:INTERNAL=ON
 WITH_DEBUG:BOOL=OFF
 WITH_EMBEDDED_SERVER:BOOL=OFF
 WITH_EXTRA_CHARSETS:STRING=all
 WITH_FAST_MUTEXES-ADVANCED:INTERNAL=1
 WITH_FAST_MUTEXES:BOOL=OFF
 WITH_FEDERATED_STORAGE_ENGINE:BOOL=OFF
 WITH_HEAP_STORAGE_ENGINE:INTERNAL=ON
 WITH_INNOBASE_STORAGE_ENGINE:BOOL=ON
 WITH_LIBEDIT:BOOL=ON
 WITH_LIBWRAP:BOOL=OFF
 WITH_MYISAMMRG_STORAGE_ENGINE:INTERNAL=ON
 WITH_MYISAM_STORAGE_ENGINE:INTERNAL=ON
 WITH_MYSQLD_LDFLAGS-ADVANCED:INTERNAL=1
 WITH_MYSQLD_LDFLAGS:STRING=
 WITHOUT_SERVER-ADVANCED:INTERNAL=1
 WITHOUT_SERVER:BOOL=OFF
 WITH_PARTITION_STORAGE_ENGINE:BOOL=ON
 WITH_PERFSCHEMA_STORAGE_ENGINE:BOOL=ON
 WITH_PIC:BOOL=OFF
 WITH_READLINE:BOOL=OFF
 WITH_SSL:STRING=no
 WITH_UNIT_TESTS:BOOL=ON
 WITH_VALGRIND:BOOL=OFF
 WITH_ZLIB:STRING=system

You are right, "cmake -L" gives some additional interesting variables,
but it also misses non-"internal" ones:
WITH_ATOMIC_LOCKS, WITH_FAST_MUTEXES, WITH_MYSQLD_LDFLAGS, and
WITHOUT_SERVER.
I would like to see them written as well, but if I have to make a choice
I agree that "cmake -L" might be the better one.


Thanks for your hints!
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