projectile-compile-project does not prompt for compilation command

[el-lute]

In a git project with CMake, when I type C-c p c, projectile executes cmake -E chdir build cmake .. && cmake --build build --target without prompting me for a compilation command. Same with C-u C-c p c. compilation-read-command is t.

I would expect to be prompted for a compilation command. That was the behavior of the previous version of projectile.

Environment & Version information

Projectile version information

Projectile version: 20170827.2053

Emacs version

GNU Emacs 25.1

Operating system

Ubuntu 17.04

[mattiasb]

This is my fault. Will look at this when I get home. Sorry! :)

[mattiasb]

@bbatsov So, I wasn't totally up to speed with how the compile commands should work in Projectile and broke expectations a bit here. The reasoning behind introducing a defun to wrap this up was that the configure step needed for some build systems (CMake, meson and autotools comes to mind) isn't really encoded in Projectile, so I wanted to do it automatically if and only if it hadn't already been done.

With this issue I'm beginning to think that that's not the way forward. Instead I propose to add a projectile-configure-project command (bound to C-c p C perhaps?) and a :configure key to projectile-register-project-type. How does that sound?

[nickenchev]

Oooor, you can make it do what it used to, which was fairly useful :)

[mattiasb]

@nickenchev that's the goal with my second proposal obviously. I already acknowledged that my PR broke expectations. The idea would be that it would work like before my PR, but the default compile command for CMake would be cmake --build build and for meson ninja -C build (and you would be able to change the command, just like before).

Still you'd want a way to set it up easily. So I propose to add a configure style command that would also be editable. The command for CMake would be mkdir -p build && cmake -E chdir build cmake .. and for meson meson build.

[nickenchev]

@mattiasb Hasty response on my part, I was under the impression that the build broke the projectile compile command. This is because I don't actually build my code directly using cmake, but use 'ninja' directly after generating my build scripts via cmake. On second thought, your new approach is actually a much better default, and I might actually start building my projects using "cmake --build [build-dir]". Saves me from keeping a .projectile file for setting the build dir. Strange though, when I run "cmake --build build" via terminal, my project compiles fine, but from within Emacs I get "Error: could not load cache".

[mattiasb]

Yeah cmake --build abstracts over the build systems, perfect for us.

My guess is that you're setting projectile-project-compilation-dir inside your .projectile file, correct? That would imply that the compilation command is run inside that directory, which means that cmake --build [build-dir] likely fails since it's looking for a subdir inside your build-directory. Unset that and it might just work.

So yeah, when I wrote my PR I didn't even see the projectile-project-compilation-dir var and my projectile-build-dir variable kind of works against that.

Thinking / working on a solution right now.

[mattiasb]

@el-lute and @nickenchev could you please try out my fix?

I need to go over the commits properly before sending a PR, but from some very quick testing it seems to work fine.

My solution adds a configure command bound to C-c p C that you should run before building.

For meson and other build-systems that enforce out-of-tree builds it will build in projectile-compilation-dir unless projectile-project-compilation-dir is set in dir-locals.

For cmake and build-systems that support- but doesn't enforce out-of-tree builds it will work the same if projectile-prefer-out-of-tree-compilation is non-nil, otherwise it will build in the project root.

Also, for both CMake and Meson you can override the commands again.

[el-lute]

@mattiasb Thanks for the work!

The docstring of projectile-compilation-dir mentions .dir_locals. That should be .dir-locals.el.

It's inconvenient for me that the build dir can be specified only relative to the source dir. My source and build dirs are on separate disks.

[mattiasb]

@el-lute Yeah I agree, and I want to fix that as well. What I did on my new branch was base it on the previous work on out-of-tree compilation made by @davidshepherd7 . That's the code that introduced the projectile-project-compilation-dir and in its docstring (and implementation) it assumes relative paths already. I'll try to add a separate PR for that later on.

Thanks for the note on .dir-locals will fix that!

[nickenchev]

@mattiasb I'll run through your changes and confirm. Also, you're correct I was setting the compilation dir inside .projectile, though taking that out was the first thing I tried in order to fix it, still no luck, very strange. I'll try the latest version and report back.

[nickenchev]

Hey @mattiasb, just working on a NDK project and realized I can no longer set my compile command as "ndk-build". Is there any way at all for me to set the compile command now?

[mattiasb]

@nickenchev did you try my branch?

Unfortunately, I'm having some health issues ATM and won't be able to get back to this until after the weekend I believe.

[mattiasb]

Sent my PR now!

[benma]

@mattiasb could you please move forward with this? I also want my compilation prompt back :)

[mattiasb]

@benma I have sent a PR fixing this. Waiting for comments from @bbatsov . I need to rebase it though, will do that tonight.

[mattiasb]

Meanwhile you can manually install my branch.

[floli]

@mattiasb Will you make your branch available on MELPA? Because the compile functionality is still broken and there seems to be no intent to fix it or at leat revert the old, working behavior.

[mattiasb]

@floli Hi, I'm sorry about this. I'm having some more pressing personal issues taking my attention right now. Meanwhile you can just clone my branch, open projectile.el and package-install-from-buffer until I get energy to respond to the review of my PR.

"Because the compile functionality is still broken and there seems to be no intent to fix it […]".

Consider your attitude. There is definitely an intent to fix this.
Like all non-funded free- and open source software you get what you pay for and if you don't like it you get to fix it yourself.