Reusing the Chibi Scheme Makefile to Build Libraries

Hi,

I needed to compile a library on a couple of different platforms. I figured the easiest way was to reuse the
information in the Makefile for Chibi Scheme itself. So, my library's Makefile looks like this:

include $(CHIBI_SCHEME_SRCDIR)/Makefile

MY_COMPILED_LIBS := my-lib/clock/system-clock$(SO)

XCFLAGS += -Wall

my-libs: $(MY_COMPILED_LIBS)

my-clean:
	rm -f $(MY_COMPILED_LIBS)

my-lib/%$(SO): my-lib/%.c $(MY_INCLUDES)
	-$(CC) $(CLIBFLAGS) -I$(PREFIX)/include $(XCPPFLAGS) $(XCFLAGS) -o $ <at>  $< -L$(PREFIX)/lib -lchibi-scheme

This works, but it's a bit of a hack. For example, I can't put my source code under the subdirectory "lib"
because that conflicts with the Chibi Scheme lib.

Does anyone have any better solution? Is this sort of reuse something that Alex would like to encourage? If
so, it might be worth moving these rules into the Chibi Scheme Makefile, so that the Makefile for a library
is simply a couple of variable definitions (e.g., MY_COMPILED_LIBS) and the include directive.

Regards,

Alan

Re: Reusing the Chibi Scheme Makefile to Build Libraries

On Thu, Mar 15, 2012 at 4:09 AM, Alan Watson <alan@...> wrote:
> Hi,
>
> I needed to compile a library on a couple of different platforms. I figured the easiest way was to reuse the
information in the Makefile for Chibi Scheme itself. So, my library's Makefile looks like this:
>
> include $(CHIBI_SCHEME_SRCDIR)/Makefile
>
> MY_COMPILED_LIBS := my-lib/clock/system-clock$(SO)
>
> XCFLAGS += -Wall
>
> my-libs: $(MY_COMPILED_LIBS)
>
> my-clean:
>        rm -f $(MY_COMPILED_LIBS)
>
> my-lib/%$(SO): my-lib/%.c $(MY_INCLUDES)
>        -$(CC) $(CLIBFLAGS) -I$(PREFIX)/include $(XCPPFLAGS) $(XCFLAGS) -o $ <at>  $< -L$(PREFIX)/lib -lchibi-scheme
>
> This works, but it's a bit of a hack. For example, I can't put my source code under the subdirectory "lib"
because that conflicts with the Chibi Scheme lib.
>
> Does anyone have any better solution? Is this sort of reuse something that Alex would like to encourage? If
so, it might be worth moving these rules into the Chibi Scheme Makefile, so that the Makefile for a library
is simply a couple of variable definitions (e.g., MY_COMPILED_LIBS) and the include directive.

Ideally you shouldn't need any of this - once chibi is installed,
the includes and libs should be in the standard paths and all
you need to do is add the -lchibi-scheme.

Re: Reusing the Chibi Scheme Makefile to Build Libraries

> If you install into a non-standard directory, or want to have
> multiple versions or configs installed at the same time, then
> a convenience to output the -I... and -L... flags would be nice.

That's a minor problem.

> Actually, this doesn't do the cross-platform $(SO) handling
> for you - it would work well with autotools, but just being
> able to include a makefile is nice.

That's the major problem. The options I can see are installing libtool, writing my own set of rules for each
platform, reusing the Chibi-Scheme Makefile.

I can see two ways to help people build libraries. The first would be to split the current Makefile into two
parts, one being specific to building Chibi Scheme and the other for building shared libraries. One could
then simply include the second part and avoid the my-foo guff. The second would be to allow people to place
their source in a virgin or near virgin Chibi Scheme source tree and have "make" build their source as well
as Chibi Scheme. Would you be interested in seeing prototypes of either or both of these? I'd be up for the
first cut.

Regards,

Alan

--

-- 
You received this message because you are subscribed to the Google Groups "chibi-scheme" group.
To post to this group, send email to chibi-scheme@...
To unsubscribe from this group, send email to chibi-scheme+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/chibi-scheme?hl=en.

Re: Reusing the Chibi Scheme Makefile to Build Libraries

On Sun, Mar 18, 2012 at 3:31 PM, Alan Watson <alan@...> wrote:
>
>> Actually, this doesn't do the cross-platform $(SO) handling
>> for you - it would work well with autotools, but just being
>> able to include a makefile is nice.
>
> That's the major problem. The options I can see are installing libtool, writing my own set of rules for each
platform, reusing the Chibi-Scheme Makefile.
>
> I can see two ways to help people build libraries.

For building Chibi libraries, the solution will be Snow
(as soon as I get around to this).

> The first would be to split the current Makefile into two parts, one being specific
> to building Chibi Scheme and the other for building shared
> libraries.

This may be of interest regardless for fellow
autoconf haters.

--

-- 
Alex

Re: Reusing the Chibi Scheme Makefile to Build Libraries

> For building Chibi libraries, the solution will be Snow
> (as soon as I get around to this).

Can Snow compile libraries that are partially or completely written in C? I may be wrong, but I don't think it can.

>> The first would be to split the current Makefile into two parts, one being specific
>> to building Chibi Scheme and the other for building shared
>> libraries.
> 
> This may be of interest regardless for fellow
> autoconf haters.

I am agnostic on autoconf, but since Chibi Scheme doesn't use it, I am follow the party line. 

I append diff that splits the Makefile into two, one specific to Chibi Scheme and one for building generic
libraries. A library's Makefile will look something like this:and installing 

   all: all-libs
   install: install-libs
   uninstall: uninstall-libs
   doc: doc-libs
   clean: clean-libs
   dist-clean: dist-clean-libs

   COMPILED_LIBS = lib/foo/bar$(SO)
   INCLUDES = lib/foo/bar.h
   SCM_LIBS = lib/foo/bar.sld lib/foo/bar.scm
   HTML_LIBS = doc/lib/foo/bar.html

   XCPPFLAGS += -I$(PREFIX)/include

Re: Reusing the Chibi Scheme Makefile to Build Libraries

On Thu, Mar 22, 2012 at 12:07 PM, Alan Watson <alan@...> wrote:
>> For building Chibi libraries, the solution will be Snow
>> (as soon as I get around to this).
>
> Can Snow compile libraries that are partially or completely written in C? I may be wrong, but I don't think
it can.

This is the new (i.e. not-yet-written) Snow for which
there will be a native chibi client with chibi-specific
extensions, including compiling C for you.

--

-- 
Alex

Re: Reusing the Chibi Scheme Makefile to Build Libraries

>> Can Snow compile libraries that are partially or completely written in C? I may be wrong, but I don't think
it can.
> 
> This is the new (i.e. not-yet-written) Snow for which
> there will be a native chibi client with chibi-specific
> extensions, including compiling C for you.

That's not Snow, but Ssometimeinthefuturemaybe! 

Alan

Why string cursors?

Well, obviously because a naive implementation of string-ref with a UTF-8 representation is O(n).

However, string-ref does not have to be naive. For example, if string-ref et al. cache the last index and its
corresponding cursor in the string header, then you can get string-cursor-like performance with
string-ref. This has the advantage of compatibility with lots of string code out there (e.g., SRFI-13).

Regards,

Alan

--

-- 
You received this message because you are subscribed to the Google Groups "chibi-scheme" group.
To post to this group, send email to chibi-scheme@...
To unsubscribe from this group, send email to chibi-scheme+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/chibi-scheme?hl=en.

Re: Why string cursors?

On Tue, Mar 27, 2012 at 6:53 AM, Alan Watson <alan@...> wrote:
> Well, obviously because a naive implementation of string-ref with a UTF-8 representation is O(n).
>
> However, string-ref does not have to be naive. For example, if string-ref et al. cache the last index and
its corresponding cursor in the string header, then you can get string-cursor-like performance with
string-ref. This has the advantage of compatibility with lots of string code out there (e.g., SRFI-13).

It may be worth trying once we have a set of suitable
benchmarks, but won't give you the same performance
in the general case, and has the disadvantage of slowing
down all string accesses (something I'm especially loathe
to do if I ever have time to finish the JIT).

Consider regex matching on a large string.  For performance,
the API wants to return a list of offsets of the subgroups.
These may be extracted in any order, but even if extracting
in order there may be large gaps between the offsets.

-- 
Alex

--

-- 
You received this message because you are subscribed to the Google Groups "chibi-scheme" group.
To post to this group, send email to chibi-scheme@...
To unsubscribe from this group, send email to chibi-scheme+unsubscribe <at> googlegroups.com.
For more options, visit this group at http://groups.google.com/group/chibi-scheme?hl=en.

[PATCH] remove unused but set variable

This resolves a compiler warning (-Wunused-but-set-variable) on gcc.

-- 
You received this message because you are subscribed to the Google Groups "chibi-scheme" group.
To post to this group, send email to chibi-scheme@...
To unsubscribe from this group, send email to chibi-scheme+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/chibi-scheme?hl=en.

# HG changeset patch
# User Travis Cross <tc <at> traviscross.com>
# Date 1332806688 0
remove unused but set variable

diff --git a/eval.c b/eval.c
index 63a2695..19d3cc7 100644
--- a/eval.c
+++ b/eval.c
 <at>  <at>  -1136,7 +1136,7  <at>  <at>  sexp sexp_load_op (sexp ctx, sexp self, sexp_sint_t n, sexp source, sexp env) {
 #if SEXP_USE_DL || SEXP_USE_STATIC_LIBS
   char *suffix;
 #endif
-  sexp tmp, out=SEXP_FALSE;
+  sexp out=SEXP_FALSE;
   sexp_gc_var4(ctx2, x, in, res);
   if (!env) env = sexp_context_env(ctx);
   sexp_assert_type(ctx, sexp_envp, SEXP_ENV, env);
 <at>  <at>  -1157,7 +1157,6  <at>  <at>  sexp sexp_load_op (sexp ctx, sexp self, sexp_sint_t n, sexp source, sexp env) {
   sexp_gc_preserve4(ctx, ctx2, x, in, res);