Hello community, here is the log from the commit of package limal-devtools checked in at Tue Mar 28 18:36:41 CEST 2006. -------- --- /work/SRC/noarch/limal-devtools/limal-devtools.changes 2006-02-16 15:44:44.000000000 +0100 +++ /work/src/done/NOARCH/limal-devtools/limal-devtools.changes 2006-03-28 17:10:59.000000000 +0200 @@ -1,0 +2,6 @@ +Tue Mar 28 16:31:05 CEST 2006 - mt@suse.de + +- version 1.1.7 +- Bug #161342: changed to check for blocxx 1.0.0 + +------------------------------------------------------------------- Old: ---- limal-devtools-1.1.6.tar.bz2 New: ---- limal-devtools-1.1.7.tar.bz2 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ limal-devtools.spec ++++++ --- /var/tmp/diff_new_pack.ekgnMz/_old 2006-03-28 18:36:20.000000000 +0200 +++ /var/tmp/diff_new_pack.ekgnMz/_new 2006-03-28 18:36:20.000000000 +0200 @@ -1,5 +1,5 @@ # -# spec file for package limal-devtools (Version 1.1.6) +# spec file for package limal-devtools (Version 1.1.7) # # Copyright (c) 2006 SUSE LINUX Products GmbH, Nuernberg, Germany. # This file and all modifications and additions to the pristine @@ -12,13 +12,13 @@ Name: limal-devtools URL: http://forge.novell.com/modules/xfmod/project/?limal -Version: 1.1.6 +Version: 1.1.7 Release: 1 License: GPL Group: System/YaST BuildRoot: %{_tmppath}/%{name}-%{version}-build BuildArchitectures: noarch -Source0: limal-devtools-1.1.6.tar.bz2 +Source0: limal-devtools-1.1.7.tar.bz2 prefix: /usr %define swiglibdir %(swig -swiglib) BuildRequires: docbook-xsl-stylesheets gcc-c++ libxslt perl-XML-Writer pkgconfig sgml-skel swig @@ -48,7 +48,7 @@ Stefan Schubert <schubi@suse.de> %prep -%setup -n limal-devtools-1.1.6 +%setup -n limal-devtools-1.1.7 %build autoreconf --force --install @@ -84,6 +84,9 @@ %{swiglibdir}/perl5/_limal*.i %changelog -n limal-devtools +* Tue Mar 28 2006 - mt@suse.de +- version 1.1.7 +- Bug #161342: changed to check for blocxx 1.0.0 * Thu Feb 16 2006 - dsieben@suse.de - version 1.1.6 - add documentation of code indention tools for limal ++++++ limal-devtools-1.1.6.tar.bz2 -> limal-devtools-1.1.7.tar.bz2 ++++++ ++++ 10909 lines of diff (skipped) ++++ retrying with extended exclude list diff -urN --exclude=CVS --exclude=.cvsignore --exclude=.svn --exclude=.svnignore --exclude Makefile.in --exclude configure --exclude config.guess --exclude '*.pot' --exclude mkinstalldirs --exclude aclocal.m4 --exclude config.sub --exclude depcomp --exclude install-sh --exclude ltmain.sh old/limal-devtools-1.1.6/VERSION new/limal-devtools-1.1.7/VERSION --- old/limal-devtools-1.1.6/VERSION 2006-02-16 15:12:16.000000000 +0100 +++ new/limal-devtools-1.1.7/VERSION 2006-03-28 16:17:41.000000000 +0200 @@ -1 +1 @@ -1.1.6 +1.1.7 diff -urN --exclude=CVS --exclude=.cvsignore --exclude=.svn --exclude=.svnignore --exclude Makefile.in --exclude configure --exclude config.guess --exclude '*.pot' --exclude mkinstalldirs --exclude aclocal.m4 --exclude config.sub --exclude depcomp --exclude install-sh --exclude ltmain.sh old/limal-devtools-1.1.6/configure.in new/limal-devtools-1.1.7/configure.in --- old/limal-devtools-1.1.6/configure.in 2006-02-16 15:32:41.000000000 +0100 +++ new/limal-devtools-1.1.7/configure.in 2006-03-28 17:09:45.000000000 +0200 @@ -3,7 +3,7 @@ dnl -- This file is generated by limalautoconf - DO NOT EDIT! -- dnl (edit configure.in.in instead) -AC_INIT(limal-devtools, 1.1.6, http://www.suse.de/feedback, limal-devtools) +AC_INIT(limal-devtools, 1.1.7, http://www.suse.de/feedback, limal-devtools) dnl Check for presence of file 'RPMNAME' AC_CONFIG_SRCDIR([RPMNAME]) @@ -17,7 +17,7 @@ AM_INIT_AUTOMAKE(tar-ustar) dnl searches for some needed programs dnl Important LiMaL variables -VERSION="1.1.6" +VERSION="1.1.7" RPMNAME="limal-devtools" RPMARCH="noarch" RPMLIB="devtools" diff -urN --exclude=CVS --exclude=.cvsignore --exclude=.svn --exclude=.svnignore --exclude Makefile.in --exclude configure --exclude config.guess --exclude '*.pot' --exclude mkinstalldirs --exclude aclocal.m4 --exclude config.sub --exclude depcomp --exclude install-sh --exclude ltmain.sh old/limal-devtools-1.1.6/devtools/bin/limalautoconf new/limal-devtools-1.1.7/devtools/bin/limalautoconf --- old/limal-devtools-1.1.6/devtools/bin/limalautoconf 2005-12-14 11:26:53.000000000 +0100 +++ new/limal-devtools-1.1.7/devtools/bin/limalautoconf 2006-03-28 16:56:49.000000000 +0200 @@ -31,7 +31,7 @@ # Jan Holesovsky <kendy@suse.cz>, 2001 # Michal Svec <msvec@suse.cz> # -# $Id: limalautoconf 1366 2005-12-14 10:24:49Z mt $ +# $Id: limalautoconf 1634 2006-03-28 14:56:48Z mt $ if ($#ARGV >= 0 && ($ARGV[0] eq "-h" || $ARGV[0] eq "--help")) { @@ -266,13 +266,13 @@ # check: BloCxx '@LIMAL-CHECKS-BLOCXX@' => 'dnl Check BloCxx installation -LIMAL_CHECK_BLOCXX([0.9.0]) +LIMAL_CHECK_BLOCXX([1.0.0]) ', # check: LiMaL (core) and blocxx large file check '@LIMAL-CHECKS-LIMAL@' => 'dnl Check BloCxx installation -LIMAL_CHECK_BLOCXX([0.9.0]) +LIMAL_CHECK_BLOCXX([1.0.0]) dnl Check LiMaL (core lib) installation LIMAL_CHECK_LIMAL([1.1.0]) diff -urN --exclude=CVS --exclude=.cvsignore --exclude=.svn --exclude=.svnignore --exclude Makefile.in --exclude configure --exclude config.guess --exclude '*.pot' --exclude mkinstalldirs --exclude aclocal.m4 --exclude config.sub --exclude depcomp --exclude install-sh --exclude ltmain.sh old/limal-devtools-1.1.6/devtools/bin/version new/limal-devtools-1.1.7/devtools/bin/version --- old/limal-devtools-1.1.6/devtools/bin/version 2006-02-16 15:33:05.000000000 +0100 +++ new/limal-devtools-1.1.7/devtools/bin/version 2006-03-28 17:10:13.000000000 +0200 @@ -1,5 +1,5 @@ #!/bin/bash -echo 1.1.6 +echo 1.1.7 diff -urN --exclude=CVS --exclude=.cvsignore --exclude=.svn --exclude=.svnignore --exclude Makefile.in --exclude configure --exclude config.guess --exclude '*.pot' --exclude mkinstalldirs --exclude aclocal.m4 --exclude config.sub --exclude depcomp --exclude install-sh --exclude ltmain.sh old/limal-devtools-1.1.6/doc/blocxx_coding_guide.txt new/limal-devtools-1.1.7/doc/blocxx_coding_guide.txt --- old/limal-devtools-1.1.6/doc/blocxx_coding_guide.txt 2005-10-10 11:31:24.000000000 +0200 +++ new/limal-devtools-1.1.7/doc/blocxx_coding_guide.txt 2006-03-28 16:08:53.000000000 +0200 @@ -1,5 +1,5 @@ ----------------------------------------------------------------------------- -Don't use bool (or OpenWBEM::Bool) in parameter lists. It makes calling code +Don't use bool (or blocxx::Bool) in parameter lists. It makes calling code impossible to understand. Use an enum instead. e.g.: f(true, false, true, true); // what the hell is this doing? // I'll have to look up the function declaration to find out! @@ -38,21 +38,16 @@ values just to insert a new item in the middle. All classes and public identifiers (anything in a header) must be in namespace -OpenWBEM. If it's not meant for external use, such as internal implementation +blocxx. If it's not meant for external use, such as internal implementation details or variables local to a translation unit, then it should be put into an unnamed namespace to avoid possible duplicate symbol link-time errors. This can be a worse issue than you might think because of providers, all the -symbols are global and can possibly conflict with symbols from other providers -or the cimom. All file names begin with OW_, and try never to create 2 -files with the same name, because of the way gcc implements unnamed namespaces, -basically the namespace isn't really unnamed, it's named the same as the file, -so two files with the same names can have conflicts in the unnamed namespace. -Also, development headers all end up being installed into the same directory, -so 2 files cannot have the same name. +symbols are global and can possibly conflict with symbols from other libraries +or the application. Capitalize type and namespace names, but not other names. -All macros must begin with OW_. Macros should be #undef'd if they are not +All macros must begin with BLOCXX_. Macros should be #undef'd if they are not meant to be re-used. Please be aware of and follow the standard c++ naming rules about identifiers @@ -74,7 +69,7 @@ } Only do that in destructors. Never let an exception escape a destructor, if -it does, it will probably abort the cimom. +it does, it will probably abort the application. There may be other occasions where this is appropriate, such as in threads that need to keep running even though one iteration of it's work has failed. In this case, the ThreadCancelledException should *never* be caught: @@ -113,25 +108,16 @@ specification. Unfortunately gcc doesn't check, and so this can easily lead to problems. -Derive all new exceptions from OpenWBEM::Exception. In most cases, you can simply -use the OW_DECLARE_EXCEPTION and OW_DEFINE_EXCEPTION macros. +Derive all new exceptions from blocxx::Exception. In most cases, you can simply +use the BLOCXX_DECLARE_EXCEPTION and BLOCXX_DEFINE_EXCEPTION macros. -Use the OW_THROW macro to throw an exception, this will automatically pass in -the filename and line number, which is a great debugging help. +Use the BLOCXX_THROW macro or its variants to throw an exception; this will +automatically pass in the filename and line number, which is a great +debugging help. -Anytime you need to report a specific WBEM error (from CIM Operations over -HTTP), throw an OpenWBEM::CIMException. Use the OW_THROWCIM and OW_THROWCIMMSG -macros to do this. +Almost any function in BloCxx may throw a std::bad_alloc if memory is exhausted. +Keep this in mind when writing exception safe code. Almost anything can throw. -Almost any function in OW may throw a std::bad_alloc if memory is exhausted. -Keep this in mind when writing exception safe code. Almost anything can -throw. - ------------------------------------------------------------------------------ -The following CIM elements are case-insensitive: Classes, Instances, Methods, -Properties, Qualifiers and Method Parameters. -Namespaces in OpenWBEM are *NOT* case-insensitive. i.e. root/CIMV2 is a -different namespace than root/cimv2. ----------------------------------------------------------------------------- c++ namespaces. NEVER put "using namespace <x>;" in a header file. Avoid putting it in a cpp @@ -139,18 +125,13 @@ use the namespace: "std::cout << std::endl" or to name each item: using std::cout; using std::endl; -A few exceptions to the rule are OpenWBEM namespaces such as WBEMFlags. -This is because we can control what are in them and won't (shouldn't) break -things by introducing conflicting names. For other namespaces that are beyond -our control we should avoid importing wholesale, because it may introduce -identifier conflicts when porting or switching to another standard library. Use unnamed namespaces instead of static function/data. Try to put new code into a namespace, this is especially important for pluggable shared libaries like providers. Don't use a class with all static functions/data, instead use a namespace. -Put all library & cimom code into namespace OpenWBEM or a sub-namespace. +Put all library code into namespace blocxx or a sub-namespace. ----------------------------------------------------------------------------- If at all possible avoid static objects that have a constructor. These can lead to the dreaded "static initialization dependency order" problem. You're @@ -165,7 +146,7 @@ non-existent code (the destructor) will be run, resulting in a segfault. ----------------------------------------------------------------------------- memory & low-level C-style code: -The #1 rule in OpenWBEM is that you can't segfault or leak memory! This is +The #1 rule in blocxx is that you can't segfault or leak memory! This is typically associated with low-level C-style code, so #2 rule is that you can't write code like that unless you have a really good reason (no, optimization isn't a good enough reason, unless you've profiled it and it's using up >30% @@ -188,8 +169,8 @@ All files must have a copyright notice. ----------------------------------------------------------------------------- Header files must have a standard include guard, and it should be like this: -#ifndef OW_FILE_NAME_HPP_INCLUDE_GUARD_ -#define OW_FILE_NAME_HPP_INCLUDE_GUARD_ +#ifndef BLOCXX_FILE_NAME_HPP_INCLUDE_GUARD_ +#define BLOCXX_FILE_NAME_HPP_INCLUDE_GUARD_ //... #endif Use all caps and put underscores between words in the filename (where it would @@ -199,7 +180,7 @@ Note that identifiers containing __ are reserved for the standard c++ library, and MUST not be used in other code. ----------------------------------------------------------------------------- -All files must include "OW_config.h" as the first include file. +All files must include "BLOCXX_config.h" as the first include file. cpp files must include it's corresponding header file as the 2nd include file. ----------------------------------------------------------------------------- Try to minimize header dependencies as much as possible. Include the minimum @@ -214,8 +195,8 @@ The other extreme of creating a forward declaration header for each class isn't a good solution either because it's too much work to create and causes a proliferation of headers. -The method we use is to use one forward declaration header per directory -(or sub-set of classes. e.g. OW_CIMFwd.hpp). When adding a new class, add +The method we use is to use forward declaration headers for common classes +(e.g. CommonFwd.hpp and ArrayFwd.hpp). When adding a new class, add it to the appropriate forward declaration header. This way, each class is defined in exactly one place, and has only one forward declaration. When you need a forward declaration, simply include the appropriate header @@ -236,7 +217,7 @@ Define a class's invariant. Only functions that maintain or check the invariant belong in a class. Other functions belong outside the class as utility/helper functions. -Use OW_ASSERT macros to validate invariants and function pre-conditions. +Use BLOCXX_ASSERT macros to validate invariants and function pre-conditions. ----------------------------------------------------------------------------- Don't use spaces to indent the code. This is so you can set your tab spacing to your own liking in your editor. If it's all spaces, you're stuck @@ -292,11 +273,11 @@ ----------------------------------------------------------------------------- Testing. Before you modify or write any new code, make a test for it. There are 2 -types of tests in OpenWBEM: unit tests and acceptance tests. The unit tests +types of tests in BloCxx: unit tests and acceptance tests. The unit tests are under test/unit, and are organized by class. You can create a new test by running the newtest.sh script and passing in as the first argument the -classname. So if you're writing a new class called OpenWBEM::Foo, you'd put -it in OW_Foo.{hpp,cpp}, you'd run ./newtest Foo. Rename testSomething to be +classname. So if you're writing a new class called blocxx::Foo, you'd put +it in blocxx/Foo.{hpp,cpp}, you'd run ./newtest Foo. Rename testSomething to be something meaningful, and create a new test function (don't forget to add it to the suite) for each different type of functionality that you're going to test. There is also the acceptance test (also known as integration or system @@ -401,14 +382,14 @@ #ifdefs For porting to different platforms it's necessary to use preprocessor #if statements. We don't have any preference wrt whether you use #ifdef, -#if defined OW_FOO or #if defined(OW_FOO). +#if defined BLOCXX_FOO or #if defined(BLOCXX_FOO). If you are simply testing for the presense of a header, add a check to -configure.in and then use #ifdef OW_HAVE_HEADER_H. +configure.in and then use #ifdef BLOCXX_HAVE_HEADER_H. Also when using a non-portable function, test for it as well. In general try to test for features in configure.in and then #ifdef on the presense of the feature. Sometime this is pointless, as in the case of win32 threads which are completely different, so just a whole chunk of the file is -enclosed inside an #ifdef OW_WIN32. Also sometimes the build system does +enclosed inside an #ifdef BLOCXX_WIN32. Also sometimes the build system does the selection of code using automake conditionals. Try to minimize the number of #ifdefs. If possible create a facade so certain functionality is only ifdef'ed in one place instead of in 10 places @@ -536,8 +517,8 @@ <strstream> header. However the replacement (<sstream>) can't be used either (until we drop support for gcc 2.95.x) because it doesn't exist on - gcc 2.95.2. Use OW_StringStream.hpp, and if you need a iostream you'll have - to write one. + gcc 2.95.2. Use blocxx/StringStream.hpp, and if you need a iostream + you'll have to write one. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Remember to have fun...