I have a makefile project with makefiles generated by Eclipse CDT (Helios, MinGW). The "clean" command does not work because the "del" command is executed with arguments like ./src/myfile.o, but on Windows this doesn't work (should be .\src\myfile.o).
How can I either tell Eclipse to use the Windows Path Separator or otherwise maybe replace the command "del" by something different (I could easily write a batch script which replaces the forward-slashes by backslashes)?
Thanks for any hints!
There is simple solution, create a makefile.defs file in your project's main directory with the following content:
RM := rm -rf
Basically this file lets you override variables from auto-generated makefile and RM is wrapper for remove command.
The best option is to download and install GnuUtils http://sourceforge.net/projects/gnuwin32/files/coreutils/5.3.0/coreutils-5.3.0.exe/download
and add the installed directory (C:\ProgramFile???\GnuWin32\bin)to your windows path and restart eclipse.Eclipse should execute rm-rf now...if it still doesnt ...restart windows and check your path again to see if it has \GnuWin32\bin ...then restart eclipse...
in your msys bin directory (C:\msys\1.0\bin on my machine) create a copy of rm.exe and rename it del.exe.
this is a hack. i am not familiar with the differences between the rm and del arguments. the base functionality is there. (delete file1 file2 filen)
in windows there is no del.exe, the delete functionality is built into CMD.exe. eclipse runs the commands in the msys shell which does not have the del functionality. this prevents you from adding a path to eclipse in which to search for del.exe.
i tried many different things to get the managed make to put "RM := rm" in the makefile but failed.
Edit the makefiles to use the mingw rm command instead?
Before you rename rm.exe to del.exe, check the path in Eclipse. The path has to have Unix path separators (forward slash, /) and not the Windows path separator (backslash, \).
This has fixed the problem on my side.
Related
OS: Ubuntu 18.04.3 LTS
I just installed neovim using sudo apt-get install neovim and added the folder and file ~/.config/nvim/vim.init. At this moment the file has no content, but when I open up nvim and type :PlugInstall I get error: E492: Not an editor command: PlugInstall. I am clueless, what is going wrong?
I think you are trying to use vim-plug without previously installing it.
I changed my plug#begin to
call plug#begin('~/.local/share/nvim/site/autoload/plug.vim')
and it worked for me now
I followed this and it worked: https://github.com/junegunn/vim-plug/wiki/tutorial
I also wrote call plug#begin('~/.config/nvim/plugged) and made a directory at that location. Then the reload command is also source ~/.config/nvim/init.vim where init.vim is the configuration file. And then I just ran :PlugInstall and it worked :D
I got this error too, but in my case I was typing :pluginstall instead of the case-sensitive :PlugInstall and you have to use the correct case or it won't work. Oddly, :PlugUpdate was able to work before :PlugInstall but that was just because I typed the case correctly.
I see I have the vim.plug correctly installed here
~/.vim/autoload/plug.vim
I also created a "plugged" folder here and I see this is where vim-plug put the downloaded files from running :PlugInstall
.vim/plugged
To be overly pedantic, I typed 'cd' to get to the user directory, then cd .vim to go into my dotted .vim folder, then "mkdir plugged" to create the plugged directory. Not sure if this was 100% necessary or if :PlugInstall would have created it by itself.
I also needed to :source ~/.vimrc between adding addition plug line items and typing :PlugInstall, so make sure you "source" or you can also completely quit and restart your Vim so it will reload your .vimrc file, otherwise it won't know anything about your file edits.
I'm on a Mac. I installed vim-plug for standard vim and this gave me this file
~/.vim/autoload/plug.vim
My .vimrc is this:
" add line numbers
set number
call plug#begin()
" The default plugin directory will be as follows:
" - Vim (Linux/macOS): '~/.vim/plugged'
" Make sure you use single quotes
Plug 'tomasiser/vim-code-dark'
Plug 'tpope/vim-sensible'
call plug#end()
I had the same problem and come here for leave my contribution ( I hadn't find this solution in anywhere ). In my case, it's caused by permissions in my linux. I always start my vim for ocults archives with:
sudo vim .vimrc
In this case, the Vim just use the default commands ( I don't know why but I think this is by the security ). If you just run:
vim .vimrc
All the user commands will be able.
In my case, I had multiple terminal windows open. I still had the Vim window open after installing vim-plug in another window. Solution was to close and re-open Vim.
Instead of
call plug#begin()
I did
call plug#begin(has('nvim') ? stdpath('data') . '/plugged' : '~/.vim/plugged')
Worked 100%
If you have followed the steps in https://github.com/junegunn/vim-plug, but still didn't work.
Try run ':source ~/.config/nvim/vim.init' in vim (not source ~/.config/nvim/vim.init in shell).
Make sure git is installed.
In my case, I was trying to do :PlugInstall in a docker container and did not have git installed. I installed git, and it worked.
We have a project (C) (not a Cygwin exe project, but some embedded cross-compiled one), which has a Makefile designed to be used from within a Cygwin environment. That is the intended use is to open a Cygwin terminal, go t the project directory and run make from there.
I can import this project in Eclipse as a Makefile project, but apparently the regular build command from within Eclipse won't work as it is trying to invoke make in the native (Windows) environment. Is there a way to make Eclipse to run the Cygwin, invoke a make command in it and have the regular CDT error parsers to work? Perhaps by creating a custom builder?
I have managed to work around this problem by using a build script invoking some cygwin commands:
build.bat:
#echo off
c:\cygwin64\bin\bash --login -c "cd %cd:\=/%; make %*"
Breakdown:
c:\cygwin64\bin\bash --login -c "<command>" - used to invoke a command from within cygwin environment
cd %cd:\=/%; - is a "dos" %cd% variable (current path) with backslashes replaced by slashes - to avoid these to be stripped down as unescaped.
make %* - invoke the cygwin make command with all of the arguments passed to this batch file - this is to let Eclipse pass the build target and/or build flags.
Now in "project build" tab in eclipse I replace the make command with build.bat and it is working like a charm. The only drawback i to have this file in addition to the other project files, but since it is pretty generic it can be reused in any project with these restrictions.
Any chance that being logged in as Administrator would change how mingw installs? I am running XP. My home directory turns out to be /c, not something in /home`.
Details: Having failed once, I removed MinGW package (mingw-get-inst-20120426) then reinstalled it. During the install of MinGW I chose every option and elected to download latest packages.
I checked my Start->Programs->Mingw->MinGW Shell properties. it is starting C:\MinGW\msys\1.0\msys.bat and the start-in directory is C:\MinGW\msys\1.0\bin. I have determined that / is C:\MinGW\msys\1.0.
But when I run the bat, at the mingw prompt echo $HOME says /c. And there is no directory named /home. echo $USERNAME = Administrator.
Can someone tell me what I did to end up with no $HOME? Do I need to make a *nix user? Or perhaps remove migw and create an XP user and use that user to reinstall mingw?
This was caused by having a Windows environment variable named HOME. It was a leftover from somehting unrelated. Once I deleted it and reinstalled mingw (without deleting the existing one) my home became /home/Administrator. Pity about the capital A, though.
In msys type cd ..
Now you're in a not really existent directory /home .
If you type cd usr
Now you're in a not really existent directory /home/usr .
you will not find home or usr in your c:\msys\1.0 directory.
MSYS is a collection of GNU utilities such as bash, make, gawk and grep to allow building of applications and programs which depend on traditionally UNIX tools to be present.
An example would be building a library that uses the autotools build system. Users will typically run "./configure" then "make" to build it. The configure shell script requires a shell script interpreter which is not present on Windows systems, but provided by MSYS.
A common misunderstanding is MSYS is "UNIX on Windows", MSYS by itself does not contain a compiler or a C library, therefore does not give the ability to magically port UNIX programs over to Windows nor does it provide any UNIX specific functionality like case-sensitive filenames.
My case: I could not find ~/msys/1.0/home/user (user is my user name)
It is resolved - the following is what I discovered.
MinGW/MSYS usually creates a home folder under C:/MinGW/msys/1.0/home/user if you install them as usual (accepting the defaults) and you executes msys.bat successfully. However, it does not create if you happened to have an environment variable called HOME. I think it was a left over from my old project.
First, check your home folder by $pwd -W ($ is a command prompt.)
Remove HOME environment variable.
Reboot
Execute msys.bat again.
Now, check where your home folder by $pwd -W
Note: Don't need to reinstall MinGW/MSYS.
(a debtor)<><
For some reason, when I type in commands I'm used to on linux, it works perfectly, as it does in bash... But in eshell, it doesn't work.
I've narrowed the problem to a trivial and small sample, as follows:
$ du
c:/Program: command not found
$ which bash
c:/Program Files (x86)/Git/bin/bash.exe
How do I get this working? (du is whatever it is by default... It's implemented in elisp, I haven't made any unusual changes there, that is, it's a compiled lisp function in `em-unix.el')
I would've expected something along the lines of "You have used 1.3 GiB of disk space", rather than that command not found error.
It doesn't use bash.exe, but it can use du.exe, when present.
On my system:
c: gutov $ which bash.exe
which: no bash.exe in ...
c: gutov $ which du.exe
h:/Apps/System/gnuwin32/bin/du.exe
From your error message I can tell that it calls some command and fails because it doesn't properly quote the path to executable (which contains spaces). Maybe you should do M-x report-emacs-bug.
Overall, I recommend:
1) Uninstall Git and reinstall it selecting the second option when asked about your PATH environment ("Run Git from the Windows Command Prompt"). This will remove the unix tools packaged with it from PATH.
2) Install in some directory without spaces and add to PATH unix tools from GnuWin32 project, or from Eli Zaretski's ports. The latter contains fewer packages overall, but it has a much faster find, for example. You can mix them.
Alternatively, maybe you can get away with just reinstalling Git into directory without spaces.
I'm trying to build a project with a specific compiler in Eclipse, and I'm using a Makefile to do the dirty work -- only problem is that it seems as if Eclipse doesn't share the same paths as my bash sessions. I've set .bash_profile and .profile (apparently Mac likes .profile just as much as .bash_profile), but neither of the exports that I've included are getting picked up. Do I need to manually set some symlinks in my /usr/bin or something like that? Or is there a way to manually set paths in eclipse?
This is because .bash_profile and .profile are read by bash when session is started. So you need to change the build command to bash -l -c "make".
Edited the Makefile and just added the absolute path:
PATH = /Users/me/yagarto/yagarto-4.6.2/bin/
TRGT = $(PATH)arm-none-eabi-