| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
This prevents unecessary rebuilds when doing consecutive make
standalone builds.
|
|
Remove more stuff when switching between make local and make standalone.
|
|
|
|
|
|
Signed-off-by: Christian Hesse <mail@eworm.de>
|
|
The local target should use the system curses library not a custom
build one. Also the two targets are now compatible with each other,
meaning that the relevant libraries are correctly rebuilt from
scratch against the correct libc.
|
|
All targets start with the package name which allows to easily
rebuild a package by removing everything matching the shell pattern
dependency/build/$package*
|
|
I hadn't noticed the `return;` line when a filetype match is found so
couldn't get my additions to this function to work. Moving the detection
to a separate function keeps that isolated and indicates that other
functions can be called from the same `vis.events.win_open` hook.
|
|
|
|
|
|
|
|
|
|
Using -std=c99 in combination with c99 does not make sense.
Some versions of Mac OS seem to have a broken wrapper implementing
the c99 utility which always generates 32-bit code instead of
targeting the native architecture.
http://stackoverflow.com/questions/4182413
Also add clang to the list of compilers to try.
|
|
|
|
On Cygwin the configure check for libtermkey fails due to unresolved
symbols from libcurses.
The pkg-config file of libtermkey lacks a reference to its
dependencies (either curses or unibilium). Since we depend on
curses anyway we can fix this by adding $LDFLAGS_CURSES to the
configure check.
|
|
This should fix configure checks on Cygwin whereas before gcc would
attempt (and fail) to write to /dev/null.exe
|
|
|
|
|
|
|
|
Originally written for the wed editor by Richard Burke, released
under the ISC license for vis.
|
|
|
|
|
|
|
|
This simplifies deployment of vis on remote systems without root
access. The idea is to extract a statically linked binary together with
the lexer syntax files into some directory, adjust $PATH to include it
and have everything just work.
For now this uses /proc/self/exe and thus only works on Linux based
systems.
|
|
|
|
|
|
|
|
This should fix `make local` (as used on travis-ci) and `make standalone`
in cases where `configure` was not run successfully due to missing
dependencies.
|
|
We want vis to be rebuilt when configuration changes, so make vis depend
on config.mk.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The new build instructions are:
$ ./configure && make && sudo make install
The configure script tries to auto detect support for various libraries
and compiler options. These choices can be overwritten by explicitly
specifing --{en,dis}able-{lua,selinux,acl}. See ./configure --help for
all supported options.
The configure script generates config.mk which should allow portable
(among GNU and BSD make) Makefiles. Manually editing config.mk is
still supported.
|
|
|
|
This makes @: (and @/) work.
|
|
|
|
|
|
The default atomic save method using rename(2) would correctly fail,
but the calling code would wrongly assume it was because of dealing
with a special (e.g. hard or symlink) file or that some other properties
(e.g. POSIX ACL, SELinux labels, permissions etc) could not be restored.
It would then go on to ftruncate(2) the file, if the following writes
then fail (which is likely if the new file content is bigger or some
other process has used up disk space in the mean time) we lose data.
This should fix it for the common case i.e. regular file where the
rename(2) based method is used. The problem persits when directly
overwriting a file.
It is unclear whether this could be improved/fixed by:
1) first appending the new file content to the old one
2) fsync the data (old||new)
3) deleteing the original file content by overwritting it with
the previously appended new file content. That is essentially
moving the new file content from the end of the file to the start.
4) ftruncate to the new file size
5) fsync the data (new)
if during 1) or 2) an error would occur we could revert the operation
by doing a ftruncate to the original file size. An error in steps 3-5
would still be fatal.
Another option would be to first write a backup file somewhere.
|
|
|
|
|
|
|
|
|
