Announcement

Collapse
No announcement yet.

CMake 3.0 Released

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • CMake 3.0 Released

    Phoronix: CMake 3.0 Released

    Version 3.0 of the CMake build system is now available with various improvements over CMake 2.x...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I have never liked cmake. I have had cmake fail on me several times. Not my code though, someone elses...

    Comment


    • #3
      Ever notice how they never make it faster or use less memory?

      Comment


      • #4
        Originally posted by Obscene_CNN View Post
        Ever notice how they never make it faster or use less memory?
        I know, totally! I've been noticing this with Windows Calculator and Notepad too.

        No, but really, are you seriously referring to memory and performance problems with CMake? If so, would you care to elaborate?

        I put CMake through some serious abuse ... I have it generating Visual Studio 2005, 2008, 2010, 2012, 2013 solutions and Makefiles comprised of hundreds of projects. I also have it running CTests on all of those too. I honestly never paid much attention to CMake's performance ... seeing as most of the the time is spent compiling!

        Oh, I almost forgot how I configure ITK, VXL and DCMTK with CMake too. ITK configures pretty slowly. But that's not really CMake's fault is it?

        EDIT:
        For those unfamiliar: ITK, VXL and DCMTK are very large projects. The first two are computer vision-related libraries and the last is for handling DICOM images.
        Last edited by nslay; 11 June 2014, 08:51 PM.

        Comment


        • #5
          Originally posted by Obscene_CNN View Post
          Ever notice how they never make it faster or use less memory?
          Ever notice how RAM prices never drop sharply, even after 2 generations of newer DDR3 memory become the standard on the majority of systems?

          Comment


          • #6
            Originally posted by Marc Driftmeyer View Post
            Ever notice how RAM prices never drop sharply, even after 2 generations of newer DDR3 memory become the standard on the majority of systems?
            That is still no excuse for bloated and slow coding. Compiling LibreOffice CMake uses about 15 minutes of cputime by itself. Every bit of resources it hogs is something I can't use while I wait for it to finish.

            Comment


            • #7
              Originally posted by Obscene_CNN View Post
              That is still no excuse for bloated and slow coding. Compiling LibreOffice CMake uses about 15 minutes of cputime by itself. Every bit of resources it hogs is something I can't use while I wait for it to finish.
              If LibreOffice takes 15 minutes to configure with CMake, then LibreOffice's CMake configuration sucks. Stupid use of CMake has nothing to do with CMake. I configure and generate solutions/Makefiles comprised of 107 projects in about ~1 minute the first run. And in seconds in subsequent configuration/generation (I constantly tweak it when I develop).

              But seeing that LibreOffice is bloated garbage to begin with, it doesn't surprise me that its CMake configurations are bloated garbage too.

              Comment


              • #8
                Originally posted by Marc Driftmeyer View Post
                Ever notice how RAM prices never drop sharply, even after 2 generations of newer DDR3 memory become the standard on the majority of systems?
                Not sure if sarcasm, but memory prices have actually continued to increase: http://pcpartpicker.com/trends/memory/

                Comment


                • #9
                  Originally posted by curaga View Post
                  Not sure if sarcasm, but memory prices have actually continued to increase: http://pcpartpicker.com/trends/memory/
                  Totally off-topic, but as someone who wants to buy 8GB of RAM I?m glad the prices have stopped going up for a few months?

                  On topic? (kind of?) I never tried CMake but I?ve been using Scons because the complexity of Make was becoming too much for me (it was getting ugly with all the different targets/options my project had). What I like about Scons is you?re actually programming your build system in Python, so the possibilities are endless and you don?t have to learn a single-purpose programming language just for the task. I haven?t done a lot with it yet though, currently wrapping my head around variant dirs?

                  Comment


                  • #10
                    Originally posted by stqn View Post
                    On topic? (kind of?) I never tried CMake but I?ve been using Scons because the complexity of Make was becoming too much for me (it was getting ugly with all the different targets/options my project had). What I like about Scons is you?re actually programming your build system in Python, so the possibilities are endless and you don?t have to learn a single-purpose programming language just for the task. I haven?t done a lot with it yet though, currently wrapping my head around variant dirs?
                    I also use SCons, and I'm very happy with it. It has allowed me to forget about targets, and write a fully-functional build system in less and much clearer code, compared to that of Autotools. With regards to Autotools, by the way, I still fear when I remember my adventures with Autoconf and Make. One of the most difficult things for me when reading other's code is understanding their build system.

                    About variant directories, you have to call each SConscript this way:
                    Code:
                    # src_dir is assumed to be the directory in which the SConscripts reside in both cases
                    # I only work with gcc and clang, and those don't have any problem with 'duplicate=0'
                    SConscript( 'src/SConscript' , variant_dir='lib' , duplicate=0 )
                    SConscript( dirs=['src'] , variant_dir='out' , duplicate=0 )
                    Paths are resolved inside each SConscript automatically, so, if you call another script, its variant directory will be created inside that of its parent. These are the relevant pages in the SCons wiki: SConscript() and VariantDir().

                    Regards.

                    Comment

                    Working...
                    X