Open WJCFerguson opened 11 years ago
This was intentional to prevent non-CMake-based projects that happen to be nested in a CMake-based source tree (third-party dependencies for instance) from being treated as CMake projects.
Perhaps I should add some way to override the normal rules. I'm not sure exactly how that would work yet.
In that case allowed suffixes as a custom var might work.
Tell me if you're swamped and would really rather I tried to work out a patch (not that I'm looking for things to do)
Sent from a tablet... On Jun 3, 2013 9:01 PM, "Alexander Lamaison" notifications@github.com wrote:
This was intentional to prevent non-CMake-based projects that happen to be nested in a CMake-based source tree (third-party dependencies for instance) from being treated as CMake projects.
Perhaps I should add some way to override the normal rules. I'm not sure exactly how that would work yet.
— Reply to this email directly or view it on GitHubhttps://github.com/alamaison/emacs-cmake-project/issues/3#issuecomment-18883342 .
I am a pretty swamped, but patch writing is not the holdup yet. First we need to work out what we would actually like the behaviour to be.
Can you explain a bit more about setting allowed suffixes? How would they contribute?
I also suffer from this.
My project structure is something like:
../project/
CMakeLists.txt
src/
CMakeLists.txt #contains add_executable(main project/main.cpp)
project/
main.cpp
On startup I get:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
file-name-as-directory(nil)
cmake-project-find-root-directory()
cmake-project-find-build-directory()
cmake-project-mode()
....
hack-one-local-variable(mode cmake-project)
c-before-hack-hook()
run-hooks(before-hack-local-variables-hook)
hack-local-variables-apply()
hack-local-variables()
normal-mode(t)
after-find-file(nil t)
find-file-noselect-1(#<buffer array.hpp> "~/projects/mplan-repos3/mlib/src/gpux/array.hpp" nil nil "/mnt/d/projects/mplan-repos3/mlib/src/gpux/array.hpp" (50258 68))
find-file-noselect("/home/hrehfeld/projects/mplan-repos3/mlib/src/gpux/array.hpp")
desktop-restore-file-buffer("/home/hrehfeld/projects/mplan-repos3/mlib/src/gpux/array.hpp" "array.hpp" nil)
desktop-create-buffer(206 "/home/hrehfeld/projects/mplan-repos3/mlib/src/gpux/array.hpp" "array.hpp" c++-mode (abbrev-mode override-global-mode subword-mode global-auto-revert-mode yas-minor-mode golden-ratio-mode company-mode TeX-PDF-mode anzu-mode irony-mode flycheck-mode helm-mode highlight-symbol-mode projectile-mode cmake-project-mode) 1774 (1728 nil) nil nil ((show-trailing-whitespace . t) (tab-width . 4) (buffer-file-coding-system . utf-8-dos) (fill-column . 100)))
eval-buffer(#<buffer *load*> nil "/home/hrehfeld/.emacs.d/dev_gnu-linux.desktop" nil t) ; Reading at buffer position 69073
load-with-code-conversion("/home/hrehfeld/.emacs.d/dev_gnu-linux.desktop" "/home/hrehfeld/.emacs.d/dev_gnu-linux.desktop" t t)
load("/home/hrehfeld/.emacs.d/dev_gnu-linux.desktop" t t t)
desktop-read()
run-hooks(after-init-hook)
command-line()
normal-top-level()
What exactly is the reason to return nil when CMakeLists.txt is not in a leaf path?
This was intentional to prevent non-CMake-based projects that happen to be nested in a CMake-based source tree (third-party dependencies for instance) from being treated as CMake projects.
I think a saner alternative would be to check if a CMakeLists.txt is found below the next .hg, .git or .svn.
You could also check for typical project root dir structures. Doesn't projectile have functionality to deal with this?
Consider this patch?:
(defun cmake-project-find-root-directory ()
"Find the top-level CMake directory."
(file-name-as-directory
(let ((cmake-file "CMakeLists.txt"))
(cond ((fboundp 'projectile-project-root)
(projectile-root-top-down-recurring (projectile-project-root) (list cmake-file)))
(t (cmake-project--upward-find-last-file cmake-file))))))
Since (cmake-project--upward-find-last-file "CMakeLists.txt") returns nil
cmake-project-find-root-directory errors out on file-name-as-directory(nil)
e.g. in our source we have a directory with CMakeLists.txt, which contains ./src and ./include where the code lives (I don't like that either :))
I'll be thinking about a fix...
Thanks