where are the files "version-xxxx.texi"

[uternet]

Such as version-scheme.texi, version-libs.text...

About ten months ago, I try to build vicare rpm package for OpenSUSE:
http://software.opensuse.org/download.html?project=home%3Auternet&package=vicare-scheme

The files above are missing, I copy them from older version. but now, When I try to build deb for Debian, they are still missing...

[okuoku]

I just failed too at CentOS7 (it also had to patch automake version to 1.13)

[marcomaggi]

I use GNU Automake 1.15, but this should not be important. The version-xxx.texi files are generated by makefile rules, which in turn are generated by Automake; these files are not under the revision control system.

If you checkout a branch from the repository: they should not be there, but they should be created if you run configure with the option --enable-maintainer-mode (as explained in the README).

If you unpack a tarball: the files should be already there, under the directory $(srcdir)/doc.

[uternet]

Thanks for replay!
These files was not found in the tarball release vicare-0.4d0pre1.tar.gz, but after pass the option --enable-maintainer-mode, build completed successfully.

Another problem is: does the support for cre2 changed in newest version? when I run configure with --with-cre2, the script reported: unknow option '--with-cre2'

[uternet]

There is another issue.

When I build the release 0.4d0pre1 with cre2, vicare reported can't found the library libcre2.so.0, I checked the directory .libs under the build directory, there exist several files inside

lrwxrwxrwx 1 uternet uternet    19 1月  14 11:58 libvicarecre2.la -> ../libvicarecre2.la
-rw-r--r-- 1 uternet uternet  1018 1月  14 11:58 libvicarecre2.lai
lrwxrwxrwx 1 uternet uternet    22 1月  14 11:58 libvicarecre2.so -> libvicarecre2.so.0.0.0
lrwxrwxrwx 1 uternet uternet    22 1月  14 11:58 libvicarecre2.so.0 -> libvicarecre2.so.0.0.0
-rwxr-xr-x 1 uternet uternet 32632 1月  14 11:58 libvicarecre2.so.0.0.0

I simply links both files to libcre2.so.0:

ln -s libvicarecre2.so.0.0.0 ./libcre2.so.0
# or
ln -s /usr/local/lib/libcres.so.0 ./libcre2.so.0

and try make again, the build completed successfully. But I don't know them right？

[marcomaggi]

These files was not found in the tarball release vicare-0.4d0pre1.tar.gz, but after pass the option --enable-maintainer-mode, build completed successfully.

I just checked the tarball and I see them in the doc directory.

Another problem is: does the support for cre2 changed in newest version? when I run configure with --with-cre2, the script reported: unknow option '--with-cre2'

The binding to the library cre2 is no more bundled with Vicare Scheme. It now has its own package.

When I build the release 0.4d0pre1 with cre2, vicare reported can't found the library libcre2.so.0, I checked the directory .libs under the build directory, there exist several files inside

Mh... not from the unpacked tarball. I guess these files are leftovers in the build directory and were created by an old make run, back when vicare-scheme still had embedded cre2 support. You can safely remove the .libs directory now and rebuild. When building from a repository checkout: it is a good idea to run make clean and even make distclean every now and then; but even these cleaning commands may leave old files in the build directory when build targets are removed from Makefile.am, so we should first run the clean command and then fetch changes from the repository.

Having leftover build files is not a big problem, anyway; if we use a separate build directory, every now and then we can just wipe it clean removing everything. The only thing that is worth saving is the config.cache file created by configure when used with the --config-cache option. In the top directory of the source tree you can see the script configure.sh I use to configure the package: I run it from a build directory like $(top_srcdir)/build; it creates a config.cache file in the top source directory, out of the build directory.

[marcomaggi]

(For some reason I see this comment in my inbox and in the lists of comments on Github, but I do not see it in the issue 88 web page itself. I reply anyway.)

Failed attempts, I can not even run the helloworld in vicare.

$ cat hi.ss
#!r6rs
(import (rnrs))
(display "Hello, world!")
(newline)
$ vicare --r6rs-script hi.ss
#Nothing printed
$ larceny -r6rs -program hi.ss
Hello, world!

anything wrong？

The standard input/output ports under Vicare behave very much like the standard input/output channels in the C language. display and newline (as called in the script) write to the standard output port, which is configured by default with block buffering; the string "Hello, world!\n" is not long enough to trigger a buffer flush operation, so nothing is printed. As shown on Vicare's home page, the hello world script needs an explicit flush operation:

(import (rnrs (6)))
(display "Hello World!\n")
(flush-output-port (current-output-port))

The behaviour of the script is different from what we see when running the REPL: at the REPL every time we hit [Return] to evaluate a form the output ports are flushed automatically.

[uternet]

Thanks a lot.

The post about "helloworld" has been deleted, because I have read the documents :-)

Vicare workers well now, I cloned the latest source code from github, configure options are:

../configure --enable-maintainer-mode --with-pthread --with-libffi --with-libiconv --with-readline --enable-sources-installation --enable-scheme-script