mawww / kakoune

mawww's experiment for a better code editor
http://kakoune.org
The Unlicense
9.94k stars 716 forks source link

Homebrew build fails to make install #286

Closed tduzan-te closed 9 years ago

tduzan-te commented 9 years ago

Reference gist-logs at https://gist.github.com/anonymous/2d65990363647cf6f476

The issue is caused because of a flag incompatibility between GNU ln and BSD ln. In the system default ln command, -r is not a valid flag. Here is what the GNU ln manpage has to say about the -r option:

‘-r’ ‘--relative’ Make symbolic links relative to the link location. Example:

      ln -srv /a/file /tmp
      '/tmp/file' -> '../a/file'

This can be solved in a couple of ways, the pathspec can be rewritten to be explicit rather than relative and drop the use of -r altogether in the Makefile, or it can check if it's being run on OSX and specify 'gln' which would cause coreutils to be a build-dep for the Homebrew formula.

I'm happy to submit a patch to do either, but don't want to make an opinionated change in a project I haven't really touched prior.

mawww commented 9 years ago

Hello, thanks for exploring this bug, I assumed -r was a POSIX option, but it is not, so not using it would have my preference.

casimir commented 9 years ago

Are you aware of a (even dirty) workaround? I was just about to try it like 3 days ago. :smile:

tduzan-te commented 9 years ago

@casimir Yes, you can replace instances of 'ln' in the makefile with 'gln' and use Homebrew to install coreutils. That's the "quick and dirty" hack which gets it working.

@mawww We'll see if I have an opportunity to dig into this further at the office today. If I do, I'll try to create a patch that solves for the use case without relying on the -r flag. I'm assuming file pathing changes would be all that's necessary during the make install step.

casimir commented 9 years ago

@tduzan a system "sed", "-i", "", "-e", "s/ln/gln/g", "src/Makefile" did the trick thanks. Although following Murphy's law it still doesn't build.

% brew install --HEAD kakoune
==> Installing kakoune from homebrew/homebrew-head-only
==> Cloning https://github.com/mawww/kakoune.git
Updating /Library/Caches/Homebrew/kakoune--git
==> Checking out branch master
==> sed -i  -e s/ln/gln/g src/Makefile
==> make -C src install PREFIX=/usr/local/Cellar/kakoune/HEAD
      Kakoune::NCursesUI::is_key_available() in .ncurses_ui.o
      Kakoune::NCursesUI::get_key() in .ncurses_ui.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [kak] Error 1
tduzan-te commented 9 years ago

That's strange, it'd indicate that you're missing a dependency but ncurses is provided by default on OS X, and Homebrew actually recommends relying on the system version rather than the Homebrew version. I install the Homebrew version myself for some specific things and pass in config-time flags when relevant to build using it, but I don't think that should be necessary here. Perhaps @mawww can weigh in on this better.

casimir commented 9 years ago

My impression is more like an object file doesn't link correctly. If you look at symbols they have nothing to do (except naming) with ncurses. Note that my C++ is a bit rusty though. I compile projects against ncurses often but never had problem.

tduzan-te commented 9 years ago

I just verified it built correctly with my patch in the #297 pull request.

casimir commented 9 years ago

I just installed it with #297. @tduzan ty!