Marcus D. Hanwell | 1 Nov 01:22 2010

Re: CMake 2.8.3-rc4 ready for testing!

On Sun, Oct 31, 2010 at 7:30 PM, Campbell Barton
<ideasman42@...> wrote:
> Hi I saw in the log you added a case for Python 2.7,
> Would you be able to add a check for Python 3.x ?
>
> For Blender 3D we use CMake and only support python 3.x series.

I added that (or part of it at least). I suspect it is too late, and
we really need to add a variable to request Python 3. That would be
too big of a change this late in the RC series. We could work on
something, with a view to getting it in CMake 2.8.4, that you could
add to Blender's CMake module path until the release.

I think for it to be general enough we would need something that
defaulted to Python 2.x, but could look for Python 3 if the project
requested it. I was not sure how best to handle this, and wanted to
make sure this release found Python 2.7. I know for most of the
project I develop we explicitly don't want Python 3 as our stuff is
not ready for it yet.

Marcus
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
(Continue reading)

Karl Wallner | 1 Nov 02:13 2010
Picon

Re: Converting a large C++-Project to CMake

Am 30.10.2010 13:54, schrieb Benjamin King:
> Hello,
>
> I'm working on a ~1.5Mio LOC C++ project and our buildsystem is a hodgepodge of handcrafted Makefiles,
shell scripts and
> qmake projects.
> I tried to convert a subset to CMake and it looks very promising so far.
>

I'm currently (as a consultant) converting ~2.5 Mio LOC C++/C from vcproj/Makefiles/qmake to cmake.
Working with big projects, different VCS, lots of developers is very different to using cmake in
small projects (few developers, single repository).
Here are some things I've learned so far:
- Split repositories (You can not put ~2.5 Mio LOC in one repository)
- Automate everything (You need: continuous build and delivery, use cdash or hudson)
- Complete build process (You need: checkout, build, packaging and install)
- Support developers (You need: developers want to work as they used to with their IDE)
- Fill gaps (You need: Find*-Modules, CMake-Macros)

> One important part of our development workflow is this:
> 1) User 'nightly' builds versions of the project every night on several development servers.
> 2) A developer is coming to the office in the morning, and copies/hardlinks the nightly build to his home
dir and
> probably patches uncommited changes from yesterday into the newly copied build.

Nightly builds are very useful to build releases. Developers should have their own source tree and update
it on
their own (daily or more often updates from repository and incremental rebuilds). Systems for continuous
integration might also be useful.

(Continue reading)

Benjamin King | 1 Nov 05:15 2010
Picon

Re: Converting a large C++-Project to CMake

Hello Alex!

> [Dependencies to generated files are] handled properly by cmake-generated
 > makefiles and project files.
> You use add_custom_command() to generate files, and if you really list all
> files the custom command generates after the OUTPUT keyword, parallel builds
> will work properly.

Great, that's good to know.

> You could use GNU make with the MS compiler, or you can use jom, which is a
> nmake compatible make for Windows, which supports parallel builds
> (http://labs.qt.nokia.com/2009/03/27/speeding-up-visual-c-qt-builds/)

Thanks again. I'll try both!

Cheers,
   Benjamin
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Benjamin King | 1 Nov 05:18 2010
Picon

Re: Converting a large C++-Project to CMake

Hi Pedro!

>> Windows and nmake don't offer any feasible way to parallelize, so we are
>> stuck there.
>
> If you haven't already, you might want to take a lot at JOM, which is
> essentially parallel nmake: http://qt.gitorious.org/qt-labs/jom. JOM
> is supported by CMake.

Thank you Pedro. One of our developers already tried to plug jom into 
our current build system, but some trouble with forward slashes in path 
names occurred. I'll give it a shot with CMake!

Cheers,
   Benjamin
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Benjamin King | 1 Nov 05:53 2010
Picon

Re: Converting a large C++-Project to CMake

Hi Karl!

> I'm currently (as a consultant) converting ~2.5 Mio LOC C++/C from
> vcproj/Makefiles/qmake to cmake.

Can you say something of the motivations for  your client to do this?

I suspect that you are expected to keep most of their development 
workflow and processes in order. Which parts are you allowed to redesign 
and which have to stay?

For us, there are also strong non-technical factors that will affect the 
decision to improve the build system, such as:
1) Is there some migration path from the old system?
2) Can we get around taking two weeks off where everybody needs to learn 
a new tool?
3) Can we keep the knowledge that went into the scripts, makefiles and 
qmake-projects of the current system?
4) Does it offer enough advantages to take the risk to change a matured 
and operative build system (albeit the latter is running at its limits)?

There are more points, but I'll need to address them all in order to 
convince anyone to even try cmake.

Right now, my plan is to convert a substantial part of the project to 
cmake. It needs to work with all our code generators. It will include a 
subproject that has a substantial amount of unit, integration and 
regression test that all need to be passed afterwards. And the migration 
path could be to just check in the CMakeLists.txt into the repository 
and be grateful that cmake builds out of source.
(Continue reading)

Michael Wild | 1 Nov 09:07 2010
Picon

Re: Converting a large C++-Project to CMake


On 1. Nov, 2010, at 5:53 , Benjamin King wrote:

> Hi Karl!
> 
> 
>> I'm currently (as a consultant) converting ~2.5 Mio LOC C++/C from
>> vcproj/Makefiles/qmake to cmake.
> 
> Can you say something of the motivations for  your client to do this?
> 
> I suspect that you are expected to keep most of their development workflow and processes in order. Which
parts are you allowed to redesign and which have to stay?
> 
> For us, there are also strong non-technical factors that will affect the decision to improve the build
system, such as:
> 1) Is there some migration path from the old system?

Well, IMHO this really depends on your current build system. If it is flexible enough you should be able to
port the parts of your project one by one.

> 2) Can we get around taking two weeks off where everybody needs to learn a new tool?

I don't think that it takes that long for everybody. There will be a few key-persons who will have to dig in
deep, but the majority of the developers will be able to add and remove sources from the CMakeLists.txt
files without even knowing the language. The same goes for include directories and link-libraries.
Running CMake is another matter, but that should take a really short time to get a grasp on, and you could
also provide a convenient wrapper script.

> 3) Can we keep the knowledge that went into the scripts, makefiles and qmake-projects of the current system?
(Continue reading)

Michael Hertling | 1 Nov 09:47 2010
Picon

Re: ADD_CUSTOM_COMMAND, crating file with echo redirection, platform independent

On 10/27/2010 08:02 PM, Arne Pagel wrote:
> Hello,
> 
> I need a custom command in my build process.
> The tool that I am using has a small problem, I have to insert a line of code in
> the output file manually:
> #include <gtk/gtk.h>
> 
> I tried this with echo and output redirection:
> echo "#include <gtk/gtk.h>" > images.c
> 
> The tool, gdk-pixbuf-csource, is not able to generate a file, therefor its output has to be 
> redirected to the file too:
> gdk-pixbuf-csource --raw pix1 ./images/pix1.png >> images.c
> 
> I can get it work one linux and win32 system, but with different syntax:
> 
> This works on a win32 System:
> 
> ADD_CUSTOM_COMMAND (OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/images.c
> 		    COMMAND ${CMAKE_COMMAND} -E echo "\#include <gtk/gtk.h>" > images.c
>                      COMMAND gdk-pixbuf-csource --raw pix1 ./images/pix1.png >> images.c
>                      DEPENDS ./images/pix1.png )
> 
> 
> This works on a linux System:
> 
> ADD_CUSTOM_COMMAND (OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/images.c
>                      COMMAND echo "\"""#include""<gtk/gtk.h>" "\"" > images.c
>                      COMMAND gdk-pixbuf-csource --raw pix1 ./images/pix1.png >> images.c
(Continue reading)

Marcel Loose | 1 Nov 09:49 2010
Picon

Re: How to work around broken Find module

Hi Alex,

On Sun, 2010-10-31 at 10:20 +0100, Alexander Neundorf wrote:
> On Thursday 28 October 2010, Marcel Loose wrote:
> > Hi all,
> >
> > What is the best way to work around a broken Find module?
> >
> > A technique I've used up till now is to wrap the broken module in a
> > module with the same name that I store in my own module directory.
This
> > way, my wrapper module will be picked up first.
> 
> Yes.
> 
> > Problem with this
> > approach is, of course, that this might break when someone is using
a
> > newer CMake in which the broken module has been fixed.
> 
> Where is the breakage there ?

I really wrap the Find module. Hence, I do a 

  include(${CMAKE_ROOT}/Modules/FindXXX.cmake)

in my own FindXXX.cmake file. Therefore, things might break when a new
version of CMake is released.

> Your module, which does what you want, still overrides the one coming
(Continue reading)

Verweij, Arjen | 1 Nov 12:35 2010

Re: Converting a large C++-Project to CMake

Benjamin,

>>
>> If you haven't already, you might want to take a lot at JOM, which is
>> essentially parallel nmake: http://qt.gitorious.org/qt-labs/jom. JOM
>> is supported by CMake.
>
>Thank you Pedro. One of our developers already tried to plug jom into
>our current build system, but some trouble with forward slashes in path
>names occurred. I'll give it a shot with CMake!

Make sure you take 0.9.4 or better, I haven't had much success with older versions, although I didn't try
every version. This was the newest at the time and it works for me (tm).

Arjen
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Adam J Richardson | 1 Nov 12:48 2010
Picon

FindODBC.cmake


Hi list,

Does anyone know of a good FindODBC.cmake I can grab from somewhere? My
Modules directory lacks one. :/

If not I'll write a quick one for inclusion in the new release. I'll
assume either Win32 standard or unixodbc is fine since they're
compatible with each other.

Thanks,
Adam J Richardson

Gmane