[cl-carbon-devel] Building Example and CL-Carbon from CVS
![](https://secure.gravatar.com/avatar/aff1c90c0534a1d1a2db996825322fbb.jpg?s=120&d=mm&r=g)
Hello, The way I've organized files in CVS may be a little weird. I wanted to keep CL-Carbon separate from anything that may use it like Example. Here is a simple step by step 'script' that should allow you to build a working application bundle from the CVS sources provided you have OpenMCL properly installed with the interfaced databases. I'm assuming ~/usr/src/ which is where I like to keep my projects. cd ~/usr/src cvs -d :pserver:anonymous@common-lisp.net:/project/cl-carbon/cvsroot login cvs -z3 -d :pserver:anonymous@common-lisp.net:/project/cl-carbon/cvsroot co Example cd Example/lib cvs -z3 -d :pserver:anonymous@common-lisp.net:/project/cl-carbon/cvsroot co CL-Carbon cd .. ln -s lib/CL-Carbon/cl-carbon.asd cl-carbon.asd sh make.sh This should result in a working Example.app in the bin directory. I've not included swank in Example. I recomend setting up another project for that. OpenGL Demo on my personal website shows how swank is used so that you can use Emacs + Slime to connect to the running application. It may be a good idea to make the build system part of CL-Carbon. That's the way Bosco handles it.
![](https://secure.gravatar.com/avatar/0499b3b49dceba9d1ee92dc27465f8ab.jpg?s=120&d=mm&r=g)
David: I finally got tired of the same old "Carbon is dead" argument that seems to keep popping up every time CL-Carbon gets mentioned on #lisp. So I did a little digging.... and I was thinking it might be nice to put a little blurb on the project web page that points out the following *Apple* applications that are Carbon apps (no Cocoa): Finder Dock iTunes and yes ... Spotlight There are more, but that ought to be enough to answer the question definitively. If you'd like, I can write up a more polished blurb, or feel free. It just would be nice to have a simple URL to reference rather than having the same discussion every time. Or even teach it to minion. ;-) --chris
![](https://secure.gravatar.com/avatar/aff1c90c0534a1d1a2db996825322fbb.jpg?s=120&d=mm&r=g)
On May 3, 2005, at 2:10 AM, Chris Curtis wrote:
I finally got tired of the same old "Carbon is dead" argument that seems to keep popping up every time CL-Carbon gets mentioned on #lisp. So I did a little digging.... and I was thinking it might be nice to put a little blurb on the project web page that points out the following *Apple* applications that are Carbon apps (no Cocoa):
Finder Dock iTunes
and yes ...
Spotlight
There are more, but that ought to be enough to answer the question definitively. If you'd like, I can write up a more polished blurb, or feel free. It just would be nice to have a simple URL to reference rather than having the same discussion every time. Or even teach it to minion. ;-)
I had a look through the logs on meme.b9.com for the past few days and didn't really see much in the way of criticism. However, a "Why Carbon" section on the project page could be useful. Hopefully anyone interested in Carbon over Cocoa will already have some good reasons though. If you can think up some specific wording, that would be great. I don't have any ideas right now. I'm thinking more about the architecture than the advocacy ;-)
![](https://secure.gravatar.com/avatar/0499b3b49dceba9d1ee92dc27465f8ab.jpg?s=120&d=mm&r=g)
I sketched out a short "why Carbon" fragment as a starting point. Nothing too fancy, just a short justification of why it's not insane. Edit at will. :-) <h2>Why Carbon?</h2> <p> Because diamonds shouldn't have marshmallows in them. <a href="http://developer.apple.com/cocoa/">Cocoa</a> is an immensely powerful tool, but for some classes of problems it's a rather awkward fit. Often <a href="http://developer.apple.com/carbon/">Carbon's</a> event model and API are simply cleaner and more natural. CL-Carbon is an attempt to make it even more natural for Common Lisp applications. </p> <p> And because it seems to come up as a question from time to time, no, Carbon is not a "dead" API. In fact, <a href="http://www.apple.com/macosx/features/ spotlight/">Spotlight</a> is written with Carbon, and that's about as new as it gets. </p>
![](https://secure.gravatar.com/avatar/cfa618515f37d21dba9ced1c7fa71e4f.jpg?s=120&d=mm&r=g)
On May 03, 2005, at 00:33, David Steuber wrote:
The way I've organized files in CVS may be a little weird. I wanted to keep CL-Carbon separate from anything that may use it like Example. Here is a simple step by step 'script' that should allow you to build a working application bundle from the CVS sources provided you have OpenMCL properly installed with the interfaced databases. I'm assuming ~/usr/src/ which is where I like to keep my projects.
cd ~/usr/src cvs -d :pserver:anonymous@common-lisp.net:/project/cl-carbon/ cvsroot login cvs -z3 -d :pserver:anonymous@common-lisp.net:/project/cl-carbon/ cvsroot co Example cd Example/lib cvs -z3 -d :pserver:anonymous@common-lisp.net:/project/cl-carbon/ cvsroot co CL-Carbon cd .. ln -s lib/CL-Carbon/cl-carbon.asd cl-carbon.asd sh make.sh
This should result in a working Example.app in the bin directory.
I'd recommend the following changes to your script: * install CL-Carbon in ~/usr/src * make the symbolic link to ../CL-Carbon/cl-carbon.asd This makes it clearer that the CL-Carbon module is separate from those modules that make use of it.
I've not included swank in Example. I recomend setting up another project for that. OpenGL Demo on my personal website shows how swank is used so that you can use Emacs + Slime to connect to the running application.
That seems acceptable. I'd even recommend that we find out if there is a way to get swank w/out getting all of slime. If so, then I'd suggest putting it in the same ~/usr/src directory and linking back to it. Of course, these are temporary hacks to start off with. We should really use defsystem or asdf to include these lisp libraries.
It may be a good idea to make the build system part of CL-Carbon. That's the way Bosco handles it.
I've not used Bosco, so I'm not totally sure what you mean. --jon
![](https://secure.gravatar.com/avatar/aff1c90c0534a1d1a2db996825322fbb.jpg?s=120&d=mm&r=g)
On May 3, 2005, at 10:10 AM, Jon Allen Boone wrote:
On May 03, 2005, at 00:33, David Steuber wrote:
This should result in a working Example.app in the bin directory.
I'd recommend the following changes to your script:
* install CL-Carbon in ~/usr/src * make the symbolic link to ../CL-Carbon/cl-carbon.asd
This makes it clearer that the CL-Carbon module is separate from those modules that make use of it.
This will certainly work. Although I have had recompile trouble due to stale dfsl files not being deleted by the make.sh script like this. It seems find does not follow symlinks. Perhaps there is a switch for that?
I've not included swank in Example. I recomend setting up another project for that. OpenGL Demo on my personal website shows how swank is used so that you can use Emacs + Slime to connect to the running application.
That seems acceptable. I'd even recommend that we find out if there is a way to get swank w/out getting all of slime. If so, then I'd suggest putting it in the same ~/usr/src directory and linking back to it.
Of course, these are temporary hacks to start off with. We should really use defsystem or asdf to include these lisp libraries.
I'm actually using ASDF. There should be an example.asd for building the example application. It depends on cl-carbon.asd. Unlike SBCL, OpenMCL does not have any default locations for systems out of the box. I've not tried to set any of that up.
It may be a good idea to make the build system part of CL-Carbon. That's the way Bosco handles it.
I've not used Bosco, so I'm not totally sure what you mean.
Bosco is an OS X application building tool created by Mikel Evins. I used it as a spring board to figure out how to create application bundles using OpenMCL. I'm not really using any Bosco code anymore, but the make.sh script is a vague remnant of what Bosco used. I'm doing things rather differently though like setting a main function in the save-application call and not even providing for Cocoa. I've just checked in some interesting changes for CL-Carbon. I believe I have vastly improved the Carbon event to CLOS method dispatch mapping code. If you want to get e-mail when CVS check ins happen, there is a cl-carbon-cvs mailing list on common-lisp.net that you can sign up for. I'm not sure when my next set of changes will be. Now that I've scratched the event handling itch (and assuming it holds up), I'm back into a thinking about what's next mode.
![](https://secure.gravatar.com/avatar/cfa618515f37d21dba9ced1c7fa71e4f.jpg?s=120&d=mm&r=g)
On May 04, 2005, at 05:41, David Steuber wrote:
This will certainly work. Although I have had recompile trouble due to stale dfsl files not being deleted by the make.sh script like this. It seems find does not follow symlinks. Perhaps there is a switch for that?
Not with the BSD utils. The Gnu version of find has a "-follow" option.
I'm actually using ASDF. There should be an example.asd for building the example application. It depends on cl-carbon.asd. Unlike SBCL, OpenMCL does not have any default locations for systems out of the box. I've not tried to set any of that up.
Sorry if I'm providing useless feedback.. I haven't had a chance to review the package yet.
Bosco is an OS X application building tool created by Mikel Evins. I used it as a spring board to figure out how to create application bundles using OpenMCL. I'm not really using any Bosco code anymore, but the make.sh script is a vague remnant of what Bosco used. I'm doing things rather differently though like setting a main function in the save-application call and not even providing for Cocoa.
I'll look into this more before commenting further...
I've just checked in some interesting changes for CL-Carbon. I believe I have vastly improved the Carbon event to CLOS method dispatch mapping code. If you want to get e-mail when CVS check ins happen, there is a cl-carbon-cvs mailing list on common- lisp.net that you can sign up for.
Cool...
I'm not sure when my next set of changes will be. Now that I've scratched the event handling itch (and assuming it holds up), I'm back into a thinking about what's next mode.
Neat. I'm planning on starting off looking at what's necessary to port to some other implementation. --jon
participants (3)
-
Chris Curtis
-
David Steuber
-
Jon Allen Boone