From: Joerg Bruehe
Date: January 22 2011 11:08am
Subject: Re: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969
List-Archive: http://lists.mysql.com/commits/129376
Message-Id: <4D3ABA9E.8090702@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi Vlad,


thank you very much for looking at my patch and commenting.

Vladislav Vaintroub wrote:
> Hi Joerg,
>=20
>> -----Original Message-----
>> From: Joerg Bruehe [mailto:joerg@stripped]
>> Sent: Freitag, 21. Januar 2011 21:40
>> To: commits@stripped
>> Subject: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#429=
69
>=20
>=20
>> +ADD_CUSTOM_TARGET(VERSION_BIN ALL
>> +  COMMAND ${CMAKE_COMMAND} -P ${CMAKE_BINARY_DIR}/version_files.cmake=

>> +  WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
>> +)
>=20
> A problem with ADD_CUSTOM_TARGET when it is used like this is that it i=
s always rebuilt (there are no inputs and not outputs , so it
> is always considered out-of-date). However there is a way to make it wo=
rk more like classic make utility with input and output,
> where rebuild is done only if input changes.

Yes, I am aware of it being rebuilt every time. While that is considered
waste of cycles in a typical compilation, I in fact favor it here:

- Creating that file should be little effort, so it should not increase
  the build time in any noticeable way.

- If we extend the rule for "VERSION_bin" by looking at further files,
  we would need to extend the dependencies in your approach. As written
  above, this has proved to be difficult.

- The brute force approach "do it always" ensures that even manual
  interventions which change any of the prerequisite files (like
  "flags.cmake") will be reflected in "VERSION_bin".

- "VERSION_bin" also contains a timestamp, IMO that should be that of
  the (last) "make" run.

>=20
> How about something like:
>=20
> ADD_CUSTOM_COMMAND(
>    OUTPUT ${CMAKE_BINARY_DIR}/VERSION_bin
>    COMMAND ${CMAKE_COMMAND} -P ${CMAKE_BINARY_DIR}/version_files.cmake
>    DEPENDS ${CMAKE_BINARY_DIR}/CMakeCache.txt
>   )
>=20
> ADD_CUSTOM_TARGET(VERSION_BIN  ALL =20
>   DEPENDS ${CMAKE_BINARY_DIR}/VERSION_bin)
>=20
> Disclaimer: I have not tried that with your patch :)   just took the te=
chnique from the Cmake FAQ (
> http://www.cmake.org/Wiki/CMake_FAQ , section "How do I generate an exe=
cutable, then use the executable to generate a file? " ) and
> applied to your example (your example is simpler, because you do not ha=
ve to generate an executable).   I assumed you generate the
> VERSION_bin from CMakeCache.txt and there are no other dependencies , a=
t least it seems so to me.

Well, the other dependency is "sql/CMakeFiles/sql.dir/flags.make", and I
wouldn't be surprised if we in the future add information which must be
collected from other files.

Sadly, I have found the cmake documentation to disagree from the acctual
behavior:
While "http://www.cmake.org/cmake/help/cmake2.6docs.html" mentions
several interesting "CMAKE_{HOST_}SYSTEM*" variables, they were not
provided in my tests (cmake 2.6.0, Debian "stable").

Also, I had trouble with rules that used files (like "flags.make" and
"CMakeCache.txt") which were created only at the end of the cmake phase.
That is also the reason why several of my new actions are guarded by an
"IF(EXISTS ...)".
Maybe this can be solved by explicitly adding information these files
will be generated, but all in all cmake seems to do some existence and
dependency checks which I had expected in the make phase only.

Because of this, I'm reluctant to do more complicated cmake constructs,
and rather favor a "keep it simple" approach. I know it isn't elegant.


However, I very much appreciate your comments and thoughts!

Regards,
J=F6rg

--=20
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