[gambit-list] Build tool, directory structure
jason.m.felice at gmail.com
Fri Mar 1 10:19:55 EST 2013
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:
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
Thanks for the patience,
On Thu, Feb 28, 2013 at 2:57 PM, Jason Felice <jason.m.felice at gmail.com>wrote:
> Forgot to include the list.
> ---------- Forwarded message ----------
> From: Jason Felice <jason.m.felice at gmail.com>
> Date: Thu, Feb 28, 2013 at 2:57 PM
> Subject: Re: [gambit-list] Build tool, directory structure
> To: Marc Feeley <feeley at 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.
> On Thu, Feb 28, 2013 at 1:30 PM, Marc Feeley <feeley at iro.umontreal.ca>wrote:
>> On 2013-02-28, at 11:03 AM, Jason Felice <jason.m.felice at gmail.com>
>> > 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,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list