List:Commits« Previous MessageNext Message »
From:Joerg Bruehe Date:October 5 2010 6:36am
Subject:Re: bzr commit into mysql-trunk-bugfixing branch (joerg:3282)
View as plain text  
Hi Vladislav, all!

Build team: please see the last paragraph, I propose to discuss this on
our next conf call.

Vladislav Vaintroub wrote:
>> -----Original Message-----
>> From: Joerg Bruehe [mailto:joerg@stripped]
>> Sent: Monday, October 04, 2010 4:59 PM
>> To: commits@stripped
>> Subject: bzr commit into mysql-trunk-bugfixing branch (joerg:3282)
>> #At file:///MySQL/REPO/Vtu/bug56267-trunk/ based on
> revid:alik@stripped
>>  3282 Joerg Bruehe	2010-10-04 [merge]
>>       Auto-upmerge the 56267 fix from 5.5 to "trunk".
>>     modified:
>>       scripts/CMakeLists.txt
>> === modified file 'scripts/CMakeLists.txt'
>> --- a/scripts/CMakeLists.txt	2010-09-13 10:26:57 +0000
>> +++ b/scripts/CMakeLists.txt	2010-10-04 14:58:50 +0000
>> @@ -81,12 +81,11 @@ INSTALL(FILES
>>  )
>>  # TCMalloc hacks
>> -ENDIF()
>> -
>> +  MESSAGE("Using tcmalloc '${MALLOC_LIB}'")
>> +ELSE()
>> +  MESSAGE("No 'MALLOC_LIB' variable")
>>  ENDIF()
> Joerg, can we silence up the debug output somewhat :)? Should every developer get 'No
> 'MALLOC_LIB' variable' ?  Should he be worried
> when it sees it?

I don't know how many developers really check the logs - from the test
failures I see, I get the impression the number may be small.

We can certainly change the wording so that it is recognized as not
being dangerous, if you think that helps. But I really want to get a
note like this in the release build logs, and not in some other file.

Once this has been realized as working correctly, we might also move
that message to the release build script - but during development, there
was a moment when I tried to access '$ENV{MALOC_LIB}' and it didn't work
even though I was convinced the variable must be set, so there was a
need for such an informational message. Being cautious, I prefer getting
the message where it really matters (within cmake) and not from some
surrounding layer/script.

> On a more serious note, why don't you store the full content of CMakeCache.txt prior
> do "make" , in your pushbuild
> environment somewhere, or print the content of it, as you currently do with
> my_config.h ? If MALLOC_LIB is set with -D, you will
> find it there, in CMakeCache.txt.  And many other interesting things too, that will
> help your team to analyze errors.

As to the "why": Maybe because nobody thought about this yet?

As to the "how": Your proposal sounds interesting to me, so I cc: the
build team; we should consider this.
However, I'd rather avoid a separate file and include it in the build
log, it makes handling so much easier and avoids several possible errors
(especially when you consider that we may have several builds for a
release, to get last-minute bugs fixed).


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

bzr commit into mysql-trunk-bugfixing branch (joerg:3282) Joerg Bruehe4 Oct
  • RE: bzr commit into mysql-trunk-bugfixing branch (joerg:3282)Vladislav Vaintroub4 Oct
    • Re: bzr commit into mysql-trunk-bugfixing branch (joerg:3282)Joerg Bruehe5 Oct