So I unblackhole'd my ObjC bridge (I'll add back optional support later, I think).  This required rebuilding the Makefile and working through the problems I've had in the past with building.

This took me 2.5 hours, and I have to admit wanting to throw my laptop at the wall.  I definitely went to bed much later than I'd intended.  Some of the issues might be documentation issues, and some might really just be my lack of attention or preconceived ideas about how to build things.  With that qualification, I'd like to give raw feedback about what I encountered and what the experience was like.

First, the new Makefile is here: https://github.com/maitria/gambit-objc/blob/master/Makefile

Issues encountered (not in order):

1. I can't have two .scm files with the same name linked together.  I had my testing programs named after different library files in the test/ directory.  If I do this, I get duplicate symbol errors.
2. I took a while to figure out that you can't use gsc -exe to build an exe with a link file.  You need to go straight to the C compiler.  This fails in very strange ways (I think it tries to read an object file as Scheme source.  I get "paren or identifier expected" with some binary garbage.)
3. There's no documentation for building a static library.  I had to deduce it from dynamic library instructions and notes.  I ended up not building a static library (but I will try that later).
4. It seems to be dark magic to invoke gambc-cc to use the compiler Gambit was configured.  It does seem doable (and I'll try it soon), but it needs environment variables like the install location which need to be extracted from gsc before "gambc-cc exe" will work.  I don't want to have to find the right compiler again unless I'm doing something cross-platform.
5. Using the word "link" in gsc -link caused me to blink.  It still seems like a misnomer, though I get it.
6. It's a bit rough to manage the two different kinds of C files in a Makefile.  They're currently in the way.  I'm going to change my Makefile to fix this.
7. I'm not currently doing automatic dependency generation, so files which are included with (include ...) or (##include ...), if modified, won't cause other sources to be rebuilt.  This shouldn't be hard to implement (and I might attempt soon).  This might be the problem I encountered before with sources not being rebuilt.

None of these seem hard to resolve.  My experience was really "death by a thousand paper cuts", including some I don't have here because they aren't gambit-specific.

Thanks for the patience,
-Jason



On Thu, Feb 28, 2013 at 2:57 PM, Jason Felice <jason.m.felice@gmail.com> wrote:

Forgot to include the list.

---------- Forwarded message ----------
From: Jason Felice <jason.m.felice@gmail.com>
Date: Thu, Feb 28, 2013 at 2:57 PM
Subject: Re: [gambit-list] Build tool, directory structure
To: Marc Feeley <feeley@iro.umontreal.ca>


Here's a historic one which I know would often run tests with stale code.


I would occasionally have to clean everything to get it to rebuild the code under test.  I never figured out why.  I had another pretty similar setup that ended up working the same way which I can't find right now.

One thing to note is that when I build the sources separately, I avoid compiling to object files because I can't predict the name in the Makefile.

-Jason



On Thu, Feb 28, 2013 at 1:30 PM, Marc Feeley <feeley@iro.umontreal.ca> wrote:

On 2013-02-28, at 11:03 AM, Jason Felice <jason.m.felice@gmail.com> wrote:

> I've been thinking about modularity problems (aside from actual module systems).  One of the problems I have is that invoking gsc from a Makefile is pretty rough because of dependencies.  I almost always end up with files not recompiling.

Before suggesting a better design I would like to understand this problem.  Can you give an example, or your current makefile, error logs, etc?

Marc