alamaison / emacs-cmake-project

A minor-mode integrating the CMake build process with the Emacs ecosystem.
GNU General Public License v3.0
34 stars 10 forks source link

If leaf directories don't contain CMakeLists.txt, M-x cmake-project-mode fails #3

Open WJCFerguson opened 11 years ago

WJCFerguson commented 11 years ago

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

alamaison commented 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.

WJCFerguson commented 11 years ago

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 .

alamaison commented 11 years ago

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?

hrehfeld commented 8 years ago

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))))))