List:Commits« Previous MessageNext Message »
From:Vladislav Vaintroub Date:January 26 2011 1:16pm
Subject:RE: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969
View as plain text  

> -----Original Message-----
> From: Joerg Bruehe [mailto:joerg.bruehe@stripped]
> Sent: Dienstag, 25. Januar 2011 20:59
> To: Vladislav Vaintroub
> Cc: commits@stripped
> Subject: Re: bzr commit into mysql-5.5-bugteam branch (joerg:3209) Bug#42969
> 

Hi Joerg,
 
> 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.

 "make install", or "make package" both depend on all targets in "make all".  "make all"
depends on all CMakeLists.txt and all
flags.cmake.  So it rebuilds everything that should be rebuilt.  It is rather impossible 
to have a discrepancy between flags as
they are listed in CMakeCache.txt and CMakeLists.txt and numerous flags.cmake's  and how
final package was produced ( I do not count
manual modifications of flags.cmake, this is too hacky to be mentioned here)

> 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.


"make install", or its equivalents in non-Makefile  environments are always used (all
those methods end up calling generated
cmake_install.cmake in build directory, possibly with some parameters).
RPM uses "make install", and CPack is using it as well. There are no packaging methods
that would not do "make install", even
homegrown MSI  packaging uses underlying method, and would happily pack produced files, if
 they had a valid installable COMPONENT.
If you talk about alternative packaging, I hope you do not mean make_win_bindist-like
hacks, I hope this kind of packaging is dead.

The method does not rely on CPack.  Rather, CPack appears to work just because it uses
"make install".

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

Is not this a  bit constructed reason?  Within the build directory, there is more complete
info with all flags.cmake, not just one
from sql directory, with all Visual Studio solution files, and CMakeCache.txt (hence with
cmake-gui, ccmake and cmake -LAH) 
The very reason to collect this info, is to package it, and use is outside of the build
directory.

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

> > 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.


Yeah, I know Debian is conservative. 

> >
> >
> > 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.

Maybe you can discuss this with reviewer . My point is that :  in current 5.5 build, there
is no precedent of unconditionally
rebuilding a target each time when "make" without parameters is involved, I think this is
a good property of the build, and I fail
to see good enough reasons to break it. Especially for something that is of no interest
for a developer.
 


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