From: Joerg Bruehe
Date: October 5 2010 6:36am
Subject: Re: bzr commit into mysql-trunk-bugfixing branch (joerg:3282)
List-Archive: http://lists.mysql.com/commits/119935
Message-Id: <4CAAC753.7000607@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi Vladislav, all!

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


Vladislav Vaintroub wrote:
>=20
>> -----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=
-20100928154346-idpjp5xvsjyvfd76
>>
>>  3282 Joerg Bruehe	2010-10-04 [merge]
>>       Auto-upmerge the 56267 fix from 5.5 to "trunk".
>>
>>     modified:
>>       scripts/CMakeLists.txt
>> =3D=3D=3D 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
>>  )
>=20
>=20
>>  # TCMalloc hacks
>> -IF($ENV{MALLOC_LIB})
>> -  SET(MALLOC_LIB $ENV{MALLOC_LIB} CACHE STRING "malloc library")
>> -ENDIF()
>> -
>>  IF(MALLOC_LIB)
>> -  INSTALL(FILES ${MALLOC_LIB} DESTINATION lib OPTIONAL)
>> +  MESSAGE("Using tcmalloc '${MALLOC_LIB}'")
>> +  INSTALL(FILES ${MALLOC_LIB} DESTINATION ${INSTALL_LIBDIR} OPTIONAL)=

>> +ELSE()
>> +  MESSAGE("No 'MALLOC_LIB' variable")
>>  ENDIF()
>=20
> Joerg, can we silence up the debug output somewhat :)? Should every dev=
eloper 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 CMakeCa=
che.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 to=
o, 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).


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