martanne
Binary releases
Would be good to have (statically-linked) binaries for Mac OS X, Linux, OpenBSD ready to download and use on a new machine.
Hi,
I agree that statically linked / self contained binaries are a useful thing to have. That is why there is a make standalone build target which attempts to create those on Linux. There might also be room for improvements in vis itself. For example the Lua based syntax highlighting files should probably also be looked up relative to the location of the executable file which would work without having to set $VIS_PATH. Bundling all required support files into a compressed self-extracting executable archive might also be an interesting option to have.
As for providing pre compiled binaries, I'm not sure it is worth the trouble of supporting all the possible combinations. Some system (Mac OS X) I do not have easy access too / no particular interest in. Ideally this should be taken care of by the various distribution packages (if vis ever sees more widespread adoption).
From a continuous integration/testing point of view it would be interesting to run some form of test suite on different systems. As for example OpenBSD's "hardened malloc" has revealed real bugs in the past. Cross compiling vis to various architectures and running the test suite via QEMU user mode emulation would be an interesting thing to do ... If this is ever done, then providing the used binaries would be an easy thing to do.
the Lua based syntax highlighting files should probably also be looked up relative to the location of the executable file which would work without having to set $VIS_PATH
As of 9b3cd2462a48ca942309e24f511db2ea1fddc95b this should now work on Linux.
I'd like to try this out on Windows, but maybe I could wait until the Linux Subsystem makes it to the stable version of Windows 10. :+1:
I'd like to try this out on Windows
Assuming you have Cygwin itself as well as the necessary development tools and the ncurses library+header files installed, make local should now build a vis binary.
I had issues with make standalone:
$ make standalone
[...]
musl-gcc -DHAVE_CONFIG_H -I. -I../include -DNDEBUG -pipe -Os -fPIE --param max-inline
-insns-single=1200 -fPIC -c ../ncurses/lib_gen.c -o ../obj_s/lib_gen.o
In file included from ./curses.priv.h:325:0,
from ../ncurses/lib_gen.c:19:
_13481.c:1372:15: error: expected ‘)’ before ‘int’
../include/curses.h:1943:56: note: in definition of macro ‘mouse_trafo’
#define mouse_trafo(y,x,to_screen) wmouse_trafo(stdscr,y,x,to_screen)
^
Makefile:1027: recipe for target '../obj_s/lib_gen.o' failed
make[3]: *** [../obj_s/lib_gen.o] Error 1
make[3]: Leaving directory '/home/sshbio/src/vis/dependency/build/ncurses-6.0/ncurses'
Makefile:113: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/sshbio/src/vis/dependency/build/ncurses-6.0'
GNUmakefile:81: recipe for target 'dependency/build/libncurses-build' failed
make[1]: *** [dependency/build/libncurses-build] Error 2
make[1]: Leaving directory '/home/sshbio/src/vis'
GNUmakefile:181: recipe for target 'standalone' failed
make: *** [standalone] Error 2
$
And I am running a Debian-based distro: uname -a gives Linux bunsenlabs 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux.
On the other hand this worked:
$ make standalone
[...]
$ printf '%s\n' "$?"
0
but while I uninstalled libtermkey, running $ ./vis still complained about this missing libtermkey.
Would it be possible to get the build out from Travis? I am looking for documentation on how to do this right now, but I never used Travis before.
[EDIT]: It seems to be possible, as written here: https://docs.travis-ci.com/user/deployment/releases
make standalone is not generally supported. If you decide to use it you are expected to fix build issues yourself. Patches to make it work on more distributions are welcome, though.
I should probably not mention it in the README, it just causes confusion.
To reduce build time, the current Travis builds are just regular dynamically linked executables which aren't really suitable as binary releases.
Better continuous integration would be welcome, especially for platforms which I do not use regularly (*BSD, Mac OS X, Cygwin). Whether this happens via Travis or some other similar service I don't really care.
It would also be nice to automatically run the clang static analyzer similar to how it is done for Coverity Scan. The test suite should be run under the various sanitizers (Address, Memory, Leak, Undefined Behavior etc). This was previously discussed on IRC, but so far nobody stepped up to actually do the work.
Ok good, if I success at building good statically linked binaries, I will put them here and describe how I fixed the issue. And patches if I can.
I still lack the skills to add more tests for now.
BSD/OS x/cygwin users over here? o/
By now we have automated Cygwin builds using AppVeyor. They are not statically linked, but require the Cygwin DLL at runtime.
I would like to set up a similar testing environment for Mac OS X, but while it compiles, some of the tests (essentially make -C test/lua) fail in the Travis CI environment. I'm not very familiar with OS X and Travis, but hope some of you guys (e.g. @soveran, @erf, @twe4ked, @terhorst, ...) can help out with fixing the issue. Thanks!
Since some time we can generate a self-contained executable with make single. Basically this is a shell script with compressed tar payload - on execution it extracts itself (including runtime file) to /tmp and executes vis.
If anybody wants to give it a try: link changed, see below
I think this is an old debate.
It is not necessarily easy to compile with all the dependencies or to be on a recent distribution that allows it to be installed.
Would it be possible to have the binary available ?
I agree that the vis-single target in the makefile is useful to have but I don't think we should have anything besides source code in the releases tab. It will just be extra work that someone needs to support.
Why do something poorly when there are already a number of available binary packages?
I'm not really up to date on the complete history behind this thread but judging by the date it was started and the issue number I think it is safe to bet that most of the packages linked were not available at the time.
At this point I think I would be in support of closing this issue.
I agree that the
vis-singletarget in the makefile is useful to have but I don't think we should have anything besides source code in the releases tab. It will just be extra work that someone needs to support.Why do something poorly when there are already a number of available binary packages?
I think the answer is simple: Windows. Everybody else (I see even MacOS packages) are being served by their normal pathways.
And, if that is resolved, then I am all for closing this ticket.
I think the answer is simple: Windows
That is fair. I can get the CI running again on windows or via cross compilation but I will still be against providing our own binary packages. We can keep compilation running and tests passing on windows but it will be up to someone else to provide prebuilt packages.
On Sun Oct 15, 2023 at 8:16 PM CEST, Randy Palamar wrote:
That is fair. I can get the CI running again on windows or via cross compilation but I will still be against providing our own binary packages. We can keep compilation running and tests passing on windows but it will be up to someone else to provide prebuilt packages.
Well, it is legitimate to close a ticket as WONTFIX. If anybody cares enough, they are free to setup GitHub actions (or whatever else) to make it work.
I've had Cygwin builds working for a while here: https://github.com/rnpnr/vis/commit/8bbcea18743d99a3ffd5d5019bb91fa5da4e6044.
There is one core test failing likely due to a bug in cygwin. Unfortunately I don't really want to invest time in determining if its correct or not to #ifdef away that test when running on cygwin so I have not applied this to master. If anyone cares about cygwin and can look into it I can add it to vis-test and restart the builds on master.