[cmake-developers] CPack API redesign

[Eric Noulard]

2010/8/12 Brad King <brad.king at kitware.com>:
> On 08/11/2010 06:04 PM, Eric Noulard wrote:
>> Is there a reason why those flags are not the default when building with gcc ?
>
> Our default behavior is to mimic the defaults of the native tools.

May be adding some extra warning flags wouldn't hurt?
For many project I'm usually using:

# Enforce strict ANSI C/C++ compliance checking
IF(NOT MINGW)
IF(CMAKE_COMPILER_IS_GNUCC)
  # we may add -Wextra if we want gcc to _really_ scream
  SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -pedantic -ansi -Wall
-Wno-unused-function")
ENDIF(CMAKE_COMPILER_IS_GNUCC)
IF(CMAKE_COMPILER_IS_GNUCXX)
  # we may add -Wextra if we want gcc to _really_ scream
  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pedantic -ansi -Wall
-Woverloaded-virtual -Wno-unused-function")
ENDIF(CMAKE_COMPILER_IS_GNUCXX)
ENDIF(NOT MINGW)

may be -pedantic and -ansi are overkill for cmake but some more
(-Wxxxx) wouldn't hurt.
I know that anynone may set this up locally but forgetting to do so is
easy too :-)


>> The commit that broke the build was mine:
>> http://cmake.org/gitweb?p=cmake.git;a=commit;h=cd7b8a03f5403603da44432470f177601b5bf42b
>> but the commiter was Brad.
>>
>> Is this the reason I did not receive the mail myself?
>>
>> If yes, would it be possible to have an option to send an e-mail to
>> both the commiter AND the author?
>
> Actually right now CDash knows about the *author* (you) but not the
> committer.  Does your email address in the commit match the one you
> used to register in CDash?

Yes same address.

>Did you set it as your "cvs/svn" user  name?

Nope, the @blah.com is missing only eric.noulard
shall I change that to match the whole mail address?

>> I yes, I didn't even thought it was possible to branch from
>> a particular commit, too simple.
>
> This is one huge advantage of distributed version control.  It is
> possible to start work from *anywhere* in history.  I sometimes use
> this to start work for a bug fix from the very commit that created
> the bug, no matter how old.  This guarantees that I can merge the
> fix with any later version without bringing in any other changes.
>
> One way I've expressed topic dependencies before is to still start
> my new topic from master, but then merge the topic dependencies
> immediately:
>
> $ git branch topicA $topicAhash
> $ git branch topicB $topicBhash
> $ git branch topicC $topicChash
> $ git checkout -b new-topic master
> $ git merge topicA
> $ git merge topicB
> $ git merge topicC
> $ edit files for actual work
> $ git commit
> ...
>
> This approach creates commits that explicitly document the dependence.
> The messages are of the form "Merge branch 'topicA' into new-topic".

I did just that without creating topicX branches.
I'll redo that in this proper way.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org