Commands not being defined/sourced

[jeetsukumaran]

Hi,

I cannot figure this out. No matter what sort of file I open, in whatever directory, I cannot seem to get the 'CMake*' commands available.

I have to manually call:

call cmake#commands#apply_global_commands()
call cmake#commands#apply_buffer_commands()

And then I get the various commands available, but the few I tried do not work because some buffer variables are not defined.

Basically, it seems that the plugin for some reason or another does not see any of files as part of a valid CMake project.

I have tried this with a clean configuration (i.e., with cmake.vim being the only plugin and no vimrc, and get the same results.).

Any ideas what might be going on?

[AntoineD]

Same issue here on vim 7.4.475.

[jalcine]

@jeetsukumaran A few questions:

• How do you define your project? You mind doing a find . -type f of the tree structure?
• What files in particular are you trying to open? A source file or a CMake file itself?

[jalcine]

As you can see here, cmake.vim only begins to set those options for buffers after obtaining its filetype. It used to work off file extensions but that was biased on my use of .{h,c}pp and .{hh,cc}.

[jeetsukumaran]

Hi, it would be great if this plugin could support arbitrary file types, as CMake is used in a very wide variety of projects.

In any case, I do not get the commands defined even in my C++ projects:

./cmake/Modules/DisableInSourceBuild.cmake
./cmake/Modules/ListFilter.cmake
./cmake/Modules/TrackGitRevision.cmake
./cmake/Modules/TrackGitRevision.cmake.in
./CMakeLists.txt
./LICENSE.txt
./README.txt
./src/CMakeLists.txt
./src/pstrudel/character.cpp
./src/pstrudel/character.hpp
./src/pstrudel/CMakeLists.txt
./src/pstrudel/dataio.hpp
./src/pstrudel/echo_pstrudel_info.sh
./src/pstrudel/profile.cpp
./src/pstrudel/profile.hpp
./src/pstrudel/pstrudel.hpp
./src/pstrudel/pstrudel_trees_main.cpp
./src/pstrudel/split.cpp
./src/pstrudel/split.hpp
./src/pstrudel/treeshape.cpp
./src/pstrudel/treeshape.hpp

regardless of the file I open.

As an example of a non-C++ project, I also have CMake as a build system in my LaTeX project:

./cmake/Modules/DisableInSourceBuild.cmake
./cmake/Modules/ListFilter.cmake
./cmake/Modules/UseLATEX.cmake
./CMakeLists.txt
./src/archipelago-model/archipelago-model.bib
./src/archipelago-model/archipelago-model.tex
./src/archipelago-model/CMakeLists.txt
./src/CMakeLists.txt

[jalcine]

Interesting. This is a design flaw then. I can get to this. My reasoning to fixing it to specific file types was to prevent the pollution of one's buffer commands in a particular buffer. That use of having CMake build LaTeX projects is new to me :dizzy:!

Also, I think I see the bigger problem here. You're disabling in-source builds? I haven't tested the plugin to do out-of-source builds. I'd have to refactor the tests to handle this. Thanks for the feedback @jeetsukumaran.

[jalcine]

This is my fault for not populating the documentation adquetely but have you tried setting g:cmake_build_directories?

[jeetsukumaran]

It certainly makes sense to avoid polluting the command namespace! Though so many different types of files can be part of a CMake project (e.g., even a C++ project may include its tex, markdown, pandoc, doxygen, etc. files as part of the CMake build) that I think this might be difficult to restrict based on filetype. I think the commands should, in fact, be available globally rather than buffer specific? For example, I can see having a test output buffer open, making a change in a project file then back to the test output buffer (or even a totally non-related file) and invoking the build from there. It would be cumbersome to navigate back to a particular buffer that happens to have the build commands defined. Of course, this makes identifying the build directory tricky.

[jeetsukumaran]

This is my fault for not populating the documentation adquetely but have you tried setting g:cmake_build_directories?

No! That might be the problem. Does this need to be defined before a buffer is loaded, e.g., in ~/.vimrc?

[jeetsukumaran]

This is my fault for not populating the documentation adquetely but have you tried setting g:cmake_build_directories? No! That might be the problem. Does this need to be defined before a buffer is loaded, e.g., in ~/.vimrc?

Ok, just tried:

let g:cmake_build_directories = ['build']

in my ~/.vimrc and no joy on the C++ project.

[jalcine]

I think the commands should, in fact, be available globally rather than buffer specific?

It's funny you mention this, it originally was globally set for most of the commands. I think that for this, it'd make sense to search for the target of a particular buffer, set b:cmake_target accordingly and then have the global command use that value to do what's necessary (like run a test, clean or build). For the most part, that should be as easy as moving some lines from cmake#commands#apply_buffer_commands() to ...#apply_global_commands().

I'm actively working on fixing the test suite so once I can get it at 100% passing, I can vet PRs for this .

[jeetsukumaran]

Thanks! Appreciate your work on this plugin!

[jalcine]

Thank you for reporting this!

[jalcine]

Okay so #54 should have handled the act of loading the commands globally instead of doing it on a buffer-by-buffer basis. Now for getting the target of said buffers.

[jalcine]

You'd be able to invoke :CMakeBuild normally in one of these files below if you used in a in-source build setup.

./src/pstrudel/character.cpp
./src/pstrudel/character.hpp
./src/pstrudel/CMakeLists.txt
./src/pstrudel/dataio.hpp
./src/pstrudel/echo_pstrudel_info.sh
./src/pstrudel/profile.cpp
./src/pstrudel/profile.hpp
./src/pstrudel/pstrudel.hpp
./src/pstrudel/pstrudel_trees_main.cpp
./src/pstrudel/split.cpp
./src/pstrudel/split.hpp
./src/pstrudel/treeshape.cpp
./src/pstrudel/treeshape.hpp

Having a out-of-source build is a bit tricky for auto-detection. What's the typical convention for defining out-of-source builds?

---

Edit: Never mind, looked it up.

[jalcine]

Alright, so I just added some changes for out-of-source builds. The thing is, you'd have to manually set g:cmake_root_binary_dir for your project since there isn't a defined practice for handling out of source builds. I'm debating doing a sibling folder check for a CMakeCache.txt but that can lead to conflicts if you have a bunch of projects with out-of-source builds. Any tips + suggestions are welcome :)

[jalcine]

Alrighty, version 0.5.2 should help you out. Let me know if anything goes wrong.

[jeetsukumaran]

Hi Jacky,

Thank you so much for your work on this! It works!

I think setting a variable to define the CMake root binary directory is fine. I wonder if making it a global string g:cmake_root_binary_dir may provide sufficient flexility, though? E.g., some projects may have multiple build directories (build/release, build/debug). Perhaps the global string variable can serve as a default, and then commands that require it can take a flag that overrides? E.g., CMakeBuild -b build/debug? But if this is too complicated or breaks other things, then the current set up is fine.

Thank you again!

[jalcine]

I wonder if making it a global string g:cmake_root_binary_dir may provide sufficient flexility, though? E.g., some projects may have multiple build directories (build/release, build/debug). Perhaps the global string variable can serve as a default, and then commands that require it can take a flag that overrides? E.g., CMakeBuild -b build/debug? But if this is too complicated or breaks other things, then the current set up is fine.

Shouldn’t be too hard to get going. Now, my only concern, though a little crazy, would be different build directories that make use of different generators. With your example, if someone used Makefiles for build/release but Ninja for build/debug, the plugin might get a bit confused since it requires input about that. I’d have to probably add a detection for the kind of project that’d be built.

I’ll look into it for later into the week. Thanks again for the feedback!

[jalcine]

Took me a bit longer than I expected but I might have to punt on having multiple build directory support. It's only because that'd require a bit of rewiring so that the plug-in's is less deterministic in what paths to choose and how it uses the build directory (it uses it for everything.) I'm open to patches to work on as always!

[jeetsukumaran]

Hi Jacky,

I would be happy to contribute a patch, but, I too am swamped right now. I will look into it a little bit down the road. Thanks for all the work so far!

[jalcine]

Hey @jeetsukumaran, you mind if I close this issue? I'd make an new issue referring to the multiple build system idea (I just ran into it when beginning to cross-compile a project, heh) and targeted it for the next minor release.

[jeetsukumaran]

No problems at all. Looking forward to the developments!

[jalcine]

Dope, I'll flesh it out before the weekend over on #60.