I noticed this fact trying to use Yggdroot/indentLine plugin, which requires conceal feature.
$ /usr/bin/vim --version
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Nov 29 2017 18:37:46)
Included patches: 1-503, 505-680, 682-1283
Compiled by root#apple.com
Normal version without GUI. Features included (+) or not (-):
...
-conceal +libcall -profile +visualextra
...
Vim > 7.3 usually supports +conceal feature.
Does anybody know why apple explicitly excluded conceal feature when compile?
Thanks in advance.
It's hard to tell why exactly that's the choice they took. Only an Apple
employee would be able to help us in explaining this. However, I don't
think it's an explicit exclusion of conceal by itself.
When you compile Vim, the configure script accepts an option called
--with-features which controls a set of features to be enabled or
disabled.
--with-features=TYPE. tiny, small, normal, big or huge (default: huge)
from src/auto/configure L1532
The conceal feature is only enabled with big or huge, and
dependent on +syntax:
/*
* +conceal 'conceal' option. Needs syntax highlighting
* as this is how the concealed text is defined.
*/
#if defined(FEAT_BIG) && defined(FEAT_SYN_HL)
# define FEAT_CONCEAL
#endif
from src/feature.h L496-502
You can see a handy list of what is included in each feature set by
checking :h +feature-list. Thus, judging by the other features, I'd
say conceal is disabled just because they are compiling with the
feature set option --with-features=normal.
It's highly recommended to install a newer and more complete Vim.
Replacing the system program might not be optimal, but that's exactly
why there are plenty of alternatives which take care of doing it right
and keeping Vim updated and complete. If you have Homebrew
installed, a simple command will do:
$ brew install vim
Alternatively, if you have MacVim you can also use its internal
executable by making an alias on your shell or something similar.
Related
I recently downloaded ncurses from here and have compiled it using ./configure and make
As it is recommended in the README, I compiled the example programs that come bundled with the package. The programs compiled without any issue, but every time I run the programs I get the following errors:
Terminal type "xterm-256color"
terminals database is inaccessible
Changing the terminal's type using TERM=xterm and export TERM don't seem to solve this issue, and I'm just stuck. Will ncurses work if I included them in my C/C++ programs, or should I make sure the examples work?
Thanks in advance
Probably you did not install the terminal database, or did not tell the programs where to find it.
OSX comes with ncurses 5.7 (old, but not the problem here), with the terminal database in /usr/share/terminfo. However by default the configure script assumes you want to install in /usr/local. You can tell the programs where there's a terminal database by setting the TERMINFO environment variable, or (better), setting TERMINFO_DIRS to list both locations (with the newer one first of course).
For a start, something like
export TERMINFO=/usr/share/terminfo
should be enough to make the examples run.
Further reading:
TERMINFO
TERMINFO_DIRS
I am learning to build a compiler using LLVM as back end.
I followed the steps on getting started with the LLVM system until setting up your environment
What is the specific location for [/path/to/your/bitcode/libs] ?
Was this mistake cause the command not found when I type in lli in a Terminal?
//I am trying to build a hello world to see through the total compiling procedure
You can put LLVM_LIB_SEARCH_PATH wherever you want. For now, you probably don't need to worry about it at all; as the documentation says, it is optional. Later, you may create bitcode (i.e. compiled VM code) functions which you would like to link into the bitcode your compiler produces. For example, you may need to create some kind of standard library and runtime environment for your executables.
That has nothing to do with the lli not found error, which is the result of the LLVM binaries either not having been installed, or having been installed somewhere which is not in your $PATH.
By default, the llvm package will configure itself for installation under the prefix /usr/local, which means that after you gmake install you should find lli and friends in places like /usr/local/bin/lli. That may or may not be in your $PATH; to find out, type
echo "$PATH"
and see if it has :/usr/local/bin: somewhere in it. If it doesn't, then you could change your PATH:
export PATH="/usr/local/bin:$PATH"
To make that permanent, you'll have to add it to your bash startup files.
But you might not want it to be installed there. I usually install software I'm playing with in my local directory tree, so that I don't have to sudo all the time. You can change the root of the installation directory tree with the --prefix argument to ./configure. (You have to do that before you build LLVM.) ./configure --help will provide some more information about configure options, but --prefix is certainly the most important one.
Whatever you do, don't do it blindly. Make sure you understand what this all means before doing it. If you plan on making a compiler, you'll need to understand some of the details of a typical build- and runtime- environment; PATH and configure scripts are on the unfortunately long list of things you should at least be somewhat familiar with.
As I understand it, some version of LLVM is already installed on Mac OS X, so you'll need to be careful that your installation doesn't interfere. The fact that bash is report that lli can't be found probably indicates that not all the tools are installed, which will make things less complicated.
I'm afraid that I don't really have any experience with installing LLVM on a Mac, but if you run into specific problems (like "my compiler doesn't work after I install LLVM") then you could ask a specific question with appropriate tags.
So this is after having dropped $30 for Mac OS 10.7 and having downloaded XCode 4.3.2. After installing the command line tools, the installed version of gcc is still 4.2.4. I need 4.7. I've installed it and set the g++ link in /usr/bin to it. But when I try to compile any program via QtCreator, I get
unrecognized command line option -Xarch_x86_64
I found this discussed in a 3-year-old bug report here, but I really couldn't follow all the different shell commands etc. and my attempt to install liblastfm failed with the same error. The comment here,
The problem is that the GCC/G++ that is normally used to compile stuff
on Macs is actually just a wrapper.
And this wrapper has Mac-Only arguments like -Xarch_x86_64, which then
get converted into the correct args.
Seems like it might be hitting the nail on the head. Aaargh! Surely there has to be some way to get around this?
I created a custom makespec - in QtSDK/Desktop/Qt/4.8.1/gcc/mkspecs, I copied the macx-g++ folder to macx-g++47. I then removed the "include(../common/g++macx.conf)" from that and included it's contents, except for the part that generates the error (i.e. the -X... thing).
I also finished with
QMAKE_CC = gcc-mp-4.7
QMAKE_CXX = g++-mp-4.7
QMAKE_LINK = $$QMAKE_CXX
QMAKE_LINK_SHLIB = $$QMAKE_CXX
QMAKE_LINK_C = $$QMAKE_CC
QMAKE_LINK_C_SHLIB = $$QMAKE_CC
...which is similar to the spec for macx-g++42.
Now, if I add '-spec macx-g++47' to the qmake args, it works.
A lot of effort for something simple...would love to know a better way.
There are several sources for newer gcc versions for OSX. Here is a small selection:
http://hpc.sourceforge.net/ (currently gcc 4.8, previous versions might also be available)
http://gcc.gnu.org/wiki/GFortranBinaries (has gcc 4.7.0 binary installer)
I assume that you did install the command line tools from within Xcode. Apple/Xcode is not always up to date with gcc, stability is more important here than bleeding edge.
What is the best method in bash to check to se if a c library is installed?
Per comments, to be more clear:
I run an install script that looks for the libexpat header file (expat.h)
Currently it is doing this via:
if ! locate libexpat.so 1> /dev/null; then
However, it should be looking for expat.h, but this still required the mlocate db to be updated first.
Any better way?
You can do as autoconf does (or, more accurately, configure scripts generated by autoconf do), and test whether you can compile a C program that uses the library.
If you don't have a compiler or the development tools installed, your options are more limited.
It also isn't clear whether you want to search in out of the way locations for the library, or if you are only concerned with it being installed in the main library directories. Also, are you looking only for shared libraries, or are you looking for static libraries - the naming conventions differ wildly depending on what you're up to, and which machine type you are doing it on (Linux and Solaris vs AIX vs MacOS X vs HP-UX (older, for PA-RISC) vs Windows, for instance). If you're looking for static libraries, you'll be hard-pressed to use them without the compiler (and probably the headers). If you're looking for shared libraries, you can use those without the development paraphernalia if you compile the program on some other machine and copy it to the target machine.
The best one I found was with #cnicutar's comment, thanks.
Specifically to do this in a bash script:
expat_loc=`whereis -b expat.h | cut -c8-`
if [[ -e "$expat_loc" ]]; then
#Something something
fi;
If you need runtime, you'll need a specific version for running some stuff. Try to run that stuff.
If you need headers, try to compile something.
I've been learning C++ and Allegro using Code::Blocks on Windows XP, and recently felt like learning Vim. However, I have no idea how to compile a program "manually" (i.e., without using an IDE).
For compiling from within Vim, I have gotten as far as setting the makeprg to gcc, but I understand I also need a makefile. What is that and how do I write one? Is it with the makefile that I can use libraries such as Allegro?
Also, I've gotten quite fond of the CB debugger (I'm using gdb). Is it possible to do something similar with Vim?
Thank you.
Look at MinGW. I would avoid Cygwin if you only need gcc and make. You'll want both MinGW and MSYS. MSYS has a windows port of make.
If you're interested in more unix utlities for the windows command line I recommend CoreUtils.
For learning make see the manual
You don't necessarily need a Makefile, but it's the preferred (and possibly sanest) way of compiling code on UNIX-like systems.
I don't know if GNU Make has a Windows port, but you can probably run it under Cygwin.
To learn more about GNU Make and Makefiles:
make (Wikipedia)
GNU Make
GNU Make Manual
Also, see this question: compile directly from vim
Mandatory edit: I don't use Windows or Cygwin. You might want to take epochwolf's advice on that department.
I'm not in expert in makefiles and debugging but I know that Vim lets you do many things.
For example if you want to compile a file with gcc, it's not very different from the usual way. In normal mode type:
:!gcc file.c -o file
In fact you can use (almost) every system command just by adding "!" in front of your command.
gdb also works with Vim
:!gdb
I hope it will help you.
To integrate vim with devenv, you can use devenv from Visual Studio to complie the project in vim. The command as follows:
Devenv SolutionName /build SolnConfigName [/project ProjName [/projectconfig ProjConfigName]]
Typicatlly, the devenv should located in C:\Program Files\Microsoft Visual Studio 8\Common7\IDE. Set it to the path of environment to make it callable from vim. We also need to make vim recognize the error messages thrown by the commandline build tool devenv. Just put the following lines in your vimrc:
" Quickfix mode: command line devenv error format
au FileType cpp set makeprg=devenv.com\ /Build\ Debug\ *[SolutionName]*
au FileType cpp set errorformat=\ %#%f(%l)\ :\ %#%t%[A-z]%#\ %m
Then You can use :make to compile and build the program from vim.
EDIT1: A few bookmarks you might find useful:
GNU make tutorial (this one uses gcc and make, so it should be right up your alley)
Another one
Win port of some of GNU utils Can was mentioning; I personally use these and haven't had any problems with them on Windows platform.
Yes, you can compile without the makefile. If your program is simple (for example, one file only) you can compile by calling the compiler and including the name of the program in the same line (don't remember how it goes with gcc). Of course, to make things easier this can be mapped to a key within vim, so you don't have to jump to command prompt and back.
If you are working on a bigger project, which consists of several files and such, than a makefile is useful. It will "search" through the files, determine dependencies, include them in the build, maybe put the source files in one directory and the resulting exe file in the other and such. So it is more of a linking and building system than just compiling.
Although the GNU make mentioned in Can Berk Guder's answer is a popular one, there are quite a number of other tooks for "building makefiles" ("makefile" has become a type of synonym for that kind of operation) - here, you can see some other options on this link. Due to its part in history vim has good support for :make, but others can be easily used as well (there are a lot of texts on this subject on VimWikia.
Well, that's it. Just my 0,2 euros :)
As long as you have GNU-make installed (with cygwin or mingw under windows), you don't need to write a makefile for single-file projects. Just run :make from vim, and that's enough.
If your project is made of several files, then you will have to write a makefile (or any equivalent for scons, aap, (b)jam, ant, ...), tune your &makeprg in consequence, and finally call :make from vim. See the relevant category in vimtips. You can of course run the compiler as you would have ran any other external tool, but you would loose the possibility to jump to the line(s) of the error(s).
NB: if you are using the win32 version of vim, and gcc-cygwin, you'll need to translate the error messages obtained. I used to maintain a perl script for this purpose, it is now part of a bigger suite (still in beta stage)
Regarding your question about debugging, it can't be done from vim under windows for the moment. The only debugger that can be integrated so far is gdb, but under linux only ; see the pyclewn (.sf.net) project.
I'm not sure about debugging, but I know an easy way to compile and run the current program as I wrote a small vim plugin to do so.
http://pastebin.com/qc5Zp2P7
It assumes you are using the g++ compiler. If not, just change the name to the compiler you're using. Save this file to whereveryouinstalledvim/ftplugin/cpp.vim
In order to compile and run the currently open program, just type shift-e while in non-editing mode.