Loading ...
Sorry, an error occurred while loading the content.
 

Re: Has anybody done any work on creating a cmake based build system for Vim?

Expand Messages
  • Zulox4
    ... In vim-cocoa projrct cmake works well for build vim binary file with the makefile, but does t works when using only the generated xcode project,and to
    Message 1 of 7 , May 26, 2013
      On Monday, May 27, 2013 12:38:09 AM UTC+2, MarcWeber wrote:
      > Excerpts from Zulox4's message of Sun May 26 23:54:33 +0200 2013:
      >
      > > The old make or nmake doesn't change frequently, and it's working well.
      >
      > 1) configure is slow, if you need to run it once only it doesn't matter.
      >
      >
      >
      > If you have to test multiple cases:
      >
      >
      >
      > If you want to test 4 cases:
      >
      > - no python
      >
      > - py 2
      >
      > - py 3
      >
      > - py 2 an py 3
      >
      > using the same "codebase", how to do that with the traditional make system efficiently?
      >
      >
      >
      > with cmake you do:
      >
      >
      >
      > mkdir case{1,2,3,4}
      >
      >
      >
      > cd case1; cmake ../ the-cmake-flags
      >
      >
      >
      > then you can run make in all case directories having 4 vims to compare
      >
      > with.
      >
      >
      >
      > Thanks for your tip. It looks like its a starting point.
      >
      >
      >
      > Marc Weber

      In vim-cocoa projrct "cmake" works well for build vim binary file with the makefile, but does't works when using only the generated xcode project,and to build only using Xcode, there is a problem with libiconv 64 bits library. I will try to build the Xcode project myself... Best regards!

      --
      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php

      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Marc Weber
      ... I ve adopted that code, and I have a vim build by cmake and gtk now. However I still have to port many configuration options. @James McCoy
      Message 2 of 7 , May 29, 2013
        > cocoa cmake
        I've adopted that code, and I have a vim build by cmake and gtk now.
        However I still have to port many configuration options.

        @James McCoy
        http://mawercer.de/tmp/variations.py

        put this into the repo directory containing src and adopt to your needs.

        You can get multiple builds easily this way:

        python variations.py -aclean,configure,build -vpython-2,python-2-3,ruby

        Which will build a python-2, a python-2 and python-3 and a vim with ruby
        enabled, huge features the way you have recommended.

        Next time just use -abuild and configure will be skipped.

        Just ignore / delete the cmake implementation for now.

        Enjoy
        Marc Weber

        --
        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Marc Weber
        follow up: I ve tried getting started with cmake and vim. I ran into two problems: P1 if_config.py and if_config3.py require different C flags to be compiled
        Message 3 of 7 , May 31, 2013
          follow up:

          I've tried getting started with cmake and vim. I ran into two problems:

          P1 if_config.py and if_config3.py require different C flags to be
          compiled with.
          P2 configure has many "magic" I don't want to rewrite (not at all using
          cmake)

          Solutions to P1)
          1) set_property (sucks, because I don't know how to pass many flags as
          list of arguments, which I cannot imagine being portable)
          However I've filed a bug report to find out whether its my
          understanding being wrong: http://public.kitware.com/Bug/view.php?id=14182
          2) create static libraries for py and py3, then link agains them

          Except that there are many additional "configuration" tests - which why
          I think rewrititing the whole configuration setup is a bad idea, unless
          there is significant value in doing so.

          So why would rewriting make sense?

          - speedup parallel execution of tests such as test whether PY_NO_RTLD_GLOBAL
          should be set. This is often basically running gcc with some header
          files and test for failure. And this is done a lot in practise.

          - target other make systems. Reasons: other operating systems, eg nmake,
          IDE files etc.

          - cmakes configuration language is not that nice. Eg read the big endian
          test with ships with cmake, and then you'll know that even a simple
          task such as running gcc looks "bloated".

          Thinking about it little more had the impression that being perfect is
          not what I want, because it leads to less readable code. What I really
          want is nice configure like syntax, allowing me to define order easily
          but run some tasks in threads and wait till they are finished.

          A dead simple ruby implementation would look liket this:


          # SlowValue: using a worker pool a computation waits till its finished
          # the great thing: because everything in ruby is an object, you can
          # catch and forward all calls (even == <= operators are just methods)
          # which can be forwarded to "wait till computation has finshed" and
          # then be run on the yielded object. Thus a laziy value does not
          # require any special treatment from user point of view.
          # simple not that well tested sample implementation: http://dpaste.com/1206087/

          slow_big_endian_test = SlowValue.new do
          sleep 3 # this simulates running gcc
          "#define HAS_BIG_ENDIAN"
          end.compute

          has_header_x = SlowValue.new do
          sleep 3
          "#define HAS_HEADER_X"
          end.compute

          config_h = []
          config_h << slow_big_endian_test
          config_h << has_header_x

          # now while trying to read the lines ruby will wait till computation has
          # finished:
          puts config_h

          This developers would be able to write code close to what they already
          know. They'd be able to use a powerful scripting language (ruby)

          The actualy "make" process should be forwarded to specialized tools such
          as make, nmake, tup, ninja etc.

          I don't want to reinvent the wheel. However after struggling with cmake again
          for simple reasos I feel reiventing the wheel does make sense.

          Does such a configuration system already exist?

          I know that big projects like blender, kde, ... switched to using cmake
          even though its not perfect. Eg big projects like blender already used
          scons, then switched to cmake (mostly).
          So using a scripting language for the build process too, seems wrong.

          Yes, I am aware that configuring only takes the smaller amount of time
          when writing patches.

          Marc Weber

          --
          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php

          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        Your message has been successfully submitted and would be delivered to recipients shortly.