Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-03-11:

[3:48] <isaacs> cadorn: yo
[3:48] <cadorn> isaacs: hi
[3:49] <isaacs> cadorn: so, one of npm's design goals is to put files where node can find them, then get the hell out of the equation.
[3:49] <cadorn> yeah, that is the idea
[3:50] <isaacs> the registry does introduce a namespace issue, but i mean, github and cpan are getting along just fine with way more packages than i foresee
[3:50] <cadorn> the CommonJS convention comes down to simply maping package locators to an FS path
[3:50] <isaacs> right
[3:50] <isaacs> node's got the first bit of that. two-string require() has a lot of opposition
[3:50] <isaacs> i personally don't care for it much
[3:50] <isaacs> npm does give you the ability to do something very much like "using", though
[3:50] <isaacs> i called it "link" but i hate that name.
[3:52] <isaacs> but, if you have a package "foo" with {"link":{ "bar" : "./lib/bar"}} then the stuff in foo/lib can just do require("./bar
[3:52] <isaacs> then other things can also do require("foo/bar") since it'll be in bar's lib folder
[3:53] <cadorn> right, you are adding namespace semantics to one global path
[3:53] <cadorn> global namespace rather
[3:53] <isaacs> right
[3:53] <isaacs> npm just links things in .node_libraries
[3:54] <cadorn> that approach is perfectly valid and makes sense for a lot of use-cases
[3:54] <isaacs> so, if you installed version 1.0.0 and 2.0.0 of package foo, you'd have foo-1.0.0 and foo-2.0.0 as modules. if you actiate foo 1.0.0, then that's "foo"
[3:55] <isaacs> i'm curious about which use cases it *doesn't* make sense for
[3:56] <cadorn> well, making sense is probably to strong
[3:57] <cadorn> lets call it: where one global namespace has drawbacks
[3:57] <isaacs> i mean, it seems like require("module", "package-name") is kind of yak-shaving-ish
[3:58] <isaacs> of course, you could have a meta-package that just has a bunch of requirements and links, and then do require("meta-package-name/module") to get it
[3:58] <cadorn> I think that is the first impression for a lot of people, but when you start using it it is so nice to use
[3:58] <Dantman> require("mypackagesystem").module("module")!
[3:58] <isaacs> i don't see what it gets you, though
[3:59] <isaacs> i mean, can't you just write that as sugar on top of the platform's very un-clever pm-agnostic require("moduleName")_?
[3:59] <cadorn> how do you identify a package with a one-arg require?
[3:59] <isaacs> cadorn: what is a "package"?
[3:59] <isaacs> it's just a folder.
[4:00] <cadorn> a folder containing a collection of modules
[4:00] <cadorn> with a package.json file declaring dependencies on other packages
[4:00] <isaacs> right
[4:00] <isaacs> but, ultimately, when you do the require(), right?
[4:00] <isaacs> it's just a folder.
[4:00] <isaacs> so if you want to identify the package, you put something in a dir, and you say "that dir is the package" and you tack it onto the path.
[4:01] <isaacs> that's it
[4:01] <cadorn> yeah, the question is how do you organize that path?
[4:02] <isaacs> cadorn: like this: http://github.com/isaacs/npm/blob/master/doc/folders.md
[4:03] <cadorn> ok, so that requires a registry to ensure names are unique
[4:03] <isaacs> cadorn: yep. or else they clobber each other.
[4:03] <cadorn> with using-packages the URL is the namespace
[4:03] <cadorn> no need for a registry
[4:03] <isaacs> still need a registry
[4:03] <cadorn> nope
[4:03] <isaacs> npm install http://example.com/path/to/blerg.tgz is a pita
[4:04] <cadorn> the path would be: example.com/path/to/blerg.tgz/package.json
[4:04] <isaacs> lame.
[4:04] <isaacs> still long and ugly
[4:05] <cadorn> a dependency can be declared with: {"location":"http://example.com/path/to/blerg.tgz"} which is sufficient to locate that package in the namespace
[4:05] <cadorn> you never see the path
[4:05] <cadorn> hence the aliasing in package.json
[4:05] <isaacs> i kinda like the way that npm does it better.
[4:05] <isaacs> simpler
[4:05] <cadorn> each package is its own little universe with no knowledge of the outside needed - it declares what it needs
[4:06] <isaacs> i'd rather run into a namespace problem, but make it easier to use and code against, and then solve that problem when i get to it
[4:06] <isaacs> i mean, with npm today, a package can declare what it needs, put it where it wants it, and have no knowledge of anything else.
[4:06] <isaacs> dependencies get linked in
[4:06] * Dantman thought someone already detailed all the horrible issues that come with trying to use the location a package is uploaded to as the package identifier.
[4:07] <cadorn> Dantman: right - hence the catalogs
[4:07] <isaacs> yeah, i think that adding another layer to this problem is the wrong way to solve it.
[4:08] <cadorn> what is required implementation wise to get using packages working is minimal
[4:08] <isaacs> cadorn: what is required to NOT use packages is even minimaler
[4:08] <cadorn> in narwhal is is a few dozen lines of code
[4:09] <cadorn> I guess we have very different visions of what future programs will look like :)
[4:10] <isaacs> i'm not so much trying to change the way that programs look
[4:10] <isaacs> i'm trying to write a way to have more fun playing with today's programs
[4:11] <isaacs> like, we've got a wiki page with a couple hundred little-to-medium things, and that's sorta working. i would like to make that easier and better in successive small steps.
[4:12] <cadorn> right and I can see that npm is a step, but I think we need to go further
[4:12] <cadorn> one aspect of using-packages is securability
[4:13] <isaacs> i'm very much thinking about have per-user databases in the registry, and perhpas a way to segregate the namespace that way on the fs, too
[4:13] <isaacs> for the securability aspect, i'm gonna be using couchdb's user stuff
[4:14] <isaacs> but user/project gives crazy exponential namespace size
[4:14] <cadorn> as soon as you do that (per-user namespaces) you are moving towards using packages :)
[4:14] <isaacs> well, sure, but it'd just put them in a subfolder in the .npm dir.
[4:14] <isaacs> and then map those to the root in some predictable way
[4:15] <cadorn> the registry can attach packages to a domain
[4:16] <isaacs> but then you could do dependencies: {"isaacs/foo":"1.0.2 - 3.2.0"} and it'd ONLY get the "foo" from me, whereas {"foo":"1.0.2 - 3.2.0"} would take any "foo" package.
[4:16] <cadorn> I have cadorn.org registered
[4:16] <cadorn> I have created my own namespace under: cadorn.org/github
[4:16] <cadorn> where packages from github are listed
[4:16] <cadorn> that gives a path of: cadorn.org/github/<package>/<version>/
[4:17] <isaacs> also, i'd like to be fine if github blew up tomorrow.
[4:17] <isaacs> i've been using their tarball auto-generation and hosting for a while, but they're *really* flaky
[4:17] <cadorn> sure, that is why it is cia a registry
[4:17] <cadorn> yeah and way to slow
[4:17] <cadorn> I'll be mirroring all tarballs that get referenced through teh PINF registry
[4:18] <isaacs> fairly soon, not sure if pre-0.1.0 or not, i'm going to start fetching the tarballs into the js-registry and storing them in couch
[4:18] <isaacs> right now, it just stores the url
[4:19] <cadorn> the idea of the registry is to give out "names" sparingly and only to apropriate projects
[4:19] <isaacs> and it's *way* simpler than the catalog.json is today
[4:20] <isaacs> what makes a project "appropriate"?
[4:20] <cadorn> so users can ahve their own catalogs and we can assign the top-namesace of "node" to the node project
[4:20] <isaacs> why care about that?
[4:20] <cadorn> because it is a top-level namespace
[4:21] <isaacs> oh, ok..
[4:21] <isaacs> well, ok, so, here's the thing...
[4:21] <cadorn> If you look at: http://registry.pinf.org/cadorn.org/github/pinf/packages/catalog.json
[4:21] <cadorn> that is my catalog
[4:21] <isaacs> essentially, even github is a one-level-deep namespace
[4:21] <isaacs> yeah, that's what i'm referring to
[4:21] <cadorn> if I want a package in the node catalog it can be mapped to
[4:21] <cadorn> http://registry.pinf.org/node/catalog.json
[4:22] <cadorn> teh http://registry.pinf.org/ part can be droped by the system if desired
[4:22] <isaacs> right, but i mean, LOOK at this thing. pointers to other catalogs? url rewriting with {tokens}? "type":"git"? this is madness!
[4:22] <cadorn> its all automatic
[4:23] <cadorn> that is what a package registry/repository does
[4:23] <isaacs> automatically generated complication isn't any less complicated.
[4:23] <cadorn> the original pacjage.json looks like this: http://github.com/cadorn/pinf/blob/master/packages/common/package.json
[4:24] <cadorn> the translation is done via a CommonJS module that can be imported into any system to do the translation
[4:24] <isaacs> i'm talking about the code that consumes it. i've avoided implementing a lot of the Packages/1.0 spec for a reason.
[4:25] <cadorn> Again, we have one module that consumes it with a standardized API you can call
[4:26] <isaacs> look, it's not that it's not standardized that bugs me. it's that there's so much yak shaving.
[4:26] <isaacs> unnecessary problems being solved way in advance of never becoming an issue.
[4:27] <cadorn> I disagree, I think they are major issue - maybe not on the system level but on the application level where developers want modular design
[4:27] <cadorn> we can go from a URL namespace to a condesed one easily, but not the other way around
[4:27] <isaacs> but developers can *have* modular design with the direction npm is going.
[4:28] <isaacs> realistically, it's a one-level namespace as it is.
[4:28] <cadorn> yeah, for node apps and the systems that use npm
[4:28] <isaacs> right
[4:28] <isaacs> and npm can install other kinds of apps that don't have tusk/narwhal idioms built into them.
[4:28] <isaacs> not idioms, i mean, dependencies
[4:29] <cadorn> my apps run across narwhal/rhino, narwhal/xulrunner. browser, node, PHP and I needed a solution that works across the board
[4:29] <isaacs> like, pure-js stuff will work in either
[4:29] <isaacs> and, actually, when/if narwhal runs on node, it won't be too hard to have npm install it ;)
[4:30] <cadorn> great, and I will be indexing npm modules in the PINF registry :)
[4:30] <isaacs> it's not much of a package manager, really. mostly lets the employees run the place.
[4:30] <isaacs> just a convenience for linking stuff into .node_libraries
[4:32] <cadorn> so how far along in npm?
[4:33] <isaacs> well, it can install tarballs (that's worked for quite a while), activate a specific version of a package, properly requires and links in deps, can safely uninstall a package (fails if there are things depending on it), links in a folder (so you can do like a dev-style "install this folder as a module" thing)
[4:33] <isaacs> links executables into /usr/local/bin, too
[4:34] <isaacs> it's coming along
[4:34] <cadorn> what about the registry?
[4:34] <isaacs> i just started the publish command, which publishes a package into the registry from a tarball url
[4:35] <isaacs> it's using http://github.com/isaacs/js-registry for that
[4:36] <cadorn> will there be support to install different stabilities of packages?
[4:36] <isaacs> yeah
[4:36] <isaacs> npm tag foo 1.0.3 stable
[4:36] <isaacs> npm tag foo 2.1.3 edge
[4:36] <isaacs> the tag can be anything, but the package/version must be in the lib
[4:36] <isaacs> the registry supports it now, just don't have it wrapped in npm yet
[4:37] <cadorn> and how are dependencies defined in package.json?
[4:37] <isaacs> { dependencies : { foo : ">=2.0.1", bar : "1.0.3 - 3.0.0", baz : ">=1.0.0 <2.0.0" } }
[4:38] <cadorn> ok, just saw the docs
[4:38] <isaacs> one-level-deep obj
[4:38] <isaacs> i'm not supporting the "ssl": { "gnutls": ["1.0", "2.0"], "openssl": "0.9.8" } thing
[4:39] <cadorn> and you are suing version ranges as well
[4:39] <isaacs> you just go ahead and require what you require.
[4:39] <isaacs> oh, yeah, foo : "1.0.3" is *exactly* version 1.0.3
[4:40] <cadorn> anyway, I would be interested to get the npm registry working with PINF where I can catalog npm modules
[4:40] <cadorn> will there be a way for me to query the packages?
[4:41] <isaacs> yeah
[4:41] <isaacs> http :)
[4:41] <isaacs> or, if you ask nice, couchdb directly
[4:41] <cadorn> and an RSS feed of some sorts to keep track of updates?
[4:41] <isaacs> the registry is a couchapp
[4:41] <isaacs> i plan to expose the _changes feed
[4:42] <cadorn> ok, great
[4:42] <cadorn> anyway, we'll keep going and see what happens :)
[4:43] <cadorn> just trying to avoid duplicating too much effort
[4:43] <isaacs> yeah, i hear ya
[4:44] <isaacs> hey, so, i just thought of something
[4:44] <isaacs> a user might write some code that works with either narwhal or node, but perhaps in slightly different ways.
[4:44] <isaacs> and in order to work right, they have to use a different "libs" dir, requiring two different package.json files.
[4:44] <isaacs> i'm to make npm look first for npm-package.json and prefer that if it finds it, otherwise, use package.json
[4:45] <cadorn> oh, I don't like that
[4:45] <cadorn> I would do:
[4:46] <isaacs> splitting up the package.json into two sections with engine keys, that seems wonky.
[4:46] <isaacs> and deep-object-merging is kind of annoying
[4:46] <cadorn> lib/common.js lib/<platform>/specific.js
[4:47] <isaacs> oh, ok, so, yeah, you could do that in your code.
[4:47] <isaacs> like, have the code decide how to require() the right thing for hte engine it's using
[4:47] <cadorn> it puts the responsibility on the developer
[4:47] <cadorn> yeah
[4:47] <cadorn> and declase both engines in package.json
[4:48] <cadorn> this is only applicable if the code works the same on both engines
[4:48] <cadorn> if not it should be two packages that have a common dependency
[4:48] <isaacs> ok... but let's say you're actually going to not include code, per se, but generate an executable for one, and use pure-js for the other, and don't want to have that extra lookup
[4:48] <isaacs> well, guess i oughtta take my own advice and not try to solve that problem before someone has it.
[4:49] <cadorn> bin/<platform>-name
[4:49] <isaacs> most js projects today have the engine in the name of the thing
[4:49] <isaacs> or they're just js
[4:49] <isaacs> i don't know of any projects that compile for node, or work with just js on narwhal, or whatever.
[4:50] <cadorn> compile for node?
[4:52] <isaacs> yeah
[4:52] <isaacs> like compile to a foo.node add-on module
[4:53] <isaacs> and use node's C stuff
[4:53] <cadorn> I will support that with PINF :)
[4:53] <isaacs> sure, and i'll support it with npm
[4:53] <isaacs> but we may support it in different ways
[4:53] <cadorn> maybe I'll use npm underneath :)
[4:53] <isaacs> hehe
[4:54] <cadorn> doing the same for yum and pear
[4:54] <isaacs> oh, i get it. ok. yeah, you should totally consume npm and the js-registry, then
[4:54] <isaacs> and tusk and cpan and ruby-gem
[4:54] <isaacs> s
[4:54] <isaacs> and all the eggs in teh cheese shop :)
[4:56] <cadorn> the idea is to be able to declare all dependencis for a program and have pinf do all the installation legwork
[4:56] <cadorn> even if that means installing curl via yum
[4:57] <isaacs> yeah, i think it sounds like pinf is very much less close to the javascript metal than npm
[4:57] <cadorn> yes, and that is intentional
[4:57] <isaacs> (very much less? wtf is up with my english tonight...)
[4:57] <cadorn> PINF is a toolchain automation platform for your entire toolchain
[4:58] <cadorn> it just happesn to use the CommonJS package spec and using-packages
[4:58] <cadorn> and it is working out *real* nice
[4:58] <isaacs> so, if you could install node with pinf, and npm as well, then npm probably be leveraged for a lot of the node projects.
[4:58] <cadorn> sure
[4:59] <cadorn> I can already install a complete narwhal/rhino app with simple pacjage.json and one JS file
[5:00] <isaacs> haha, i dunno, i've seen some pretty big js files in myday
[5:00] <isaacs> saying there's only 1 might not be something to brag about ;P
[5:00] <cadorn> a 5 line JSGI APP
[5:01] <cadorn> I have to go, I'll be wrapping npm as soon as modules become available
[5:02] <cadorn> looking forward to get that working
[5:02] <isaacs> kewl!
[5:02] <isaacs> me too.
[5:02] <cadorn> deploy node apps via gists :)
[5:03] <cadorn> ttyl
[5:04] <cadorn> oh, once the node narwhal support is solid I am hoping to use node for PINF
[5:05] <cadorn> especially the PINF continuous integration server
[10:01] <ashb> bah people without persistent connection
[10:26] <ondras> :)
[13:05] <Wes-> ashb: Any chance you have 20 minutes to help me debug a Snow Leopard build problem?
[13:05] <ashb> i can try
[13:06] <Wes-> ashb: do build inside your tracemonkey repo, or do you do outside-the-tree buidl?
[13:06] <ashb> out of tree
[13:06] <Wes-> *phew*
[13:06] <ashb> typically js/build-rel
[13:07] <Wes-> ashb: Okay, can you pop into wherever you keep your source trees and hg clone https://gpsee.googlecode.com/hg/ gpsee ?
[13:07] <ashb> cloning
[13:08] <Wes-> ashb: And you'll need ftp://sources.redhat.com/pub/libffi/libffi-3.0.8.tar.gz untarred somewhere (suggest directly under homedir)
[13:09] <ashb> okay
[13:10] <Wes-> ashb: copy local_config.mk.sample to local_config.mk -- for each of gpsee, gpsee/spidermonkey and gpsee/libffi
[13:11] <Wes-> ashb: If you picked a place other than homedir to untar libffi, you will need to edit libffi/local_config.mk to indicate where
[13:11] <ashb> yeah i see that
[13:12] <Wes-> ashb: you'll also need to edit spidermonkey/local_config.mk to set SPIDERMONKEY_SRC -- location of js/src in your tracemonkey repo
[13:12] <Wes-> (I also build out-of-tree)
[13:13] <ashb> done
[13:13] <Wes-> ashb: cd libffi; make build; make install
[13:13] <Wes-> ashb: cd ../spidermonkey; make build; make install
[13:13] <Wes-> ashb: cd ..; make build; make install
[13:13] <Wes-> assuming all that works right (it should)
[13:14] <Wes-> otool -L gsr
[13:14] <ashb> where will that make install go to?
[13:14] <Wes-> and tell my if libgpsee.dylib is in there
[13:14] <Wes-> ashb: OH!
[13:14] <ashb> ;)
[13:14] <Wes-> ashb: local_config.mk controls that; on Darwin the default is all /opt/local/gpsee/*
[13:14] <ashb> make -n does *wierd* stuff
[13:14] <ashb> k
[13:14] <ashb> $ make install -n
[13:14] <ashb> make n QUIET=True build
[13:14] <ashb> make[1]: *** No rule to make target `n'. Stop.
[13:14] <ashb> make: *** [install] Error 2
[13:15] <Wes-> I don't test with -n :)
[13:15] <Wes-> ashb: If you don't want to sudo the install rule, pre-make /opt/local/gpsee
[13:15] <Wes-> ashb: and give yourself write perms
[13:16] <ashb> it didn't exist so just got created fine
[13:16] <Wes-> beauty, you must have write access to /opt/local
[13:17] <ashb> (i dont use macports or fink as i htink they suck)
[13:17] <ashb> /opt didn't exist
[13:17] <Wes-> I'm not overly happy with macports, haven't tried fink, but really want an appliance
[13:17] <ashb> homebrew
[13:17] <ashb> it just feels so much nicer
[13:17] <Wes-> I'm really happy with Aquamacs, BTW, if you are an emacs user
[13:17] * Wes- makes a note to try homebrew
[13:18] <ashb> http://github.com/mxcl/homebrew
[13:19] <ashb> there is a homepage for it somewhere i think
[13:20] <ashb> Wes-: bad moneky. no cookie.
[13:20] <ashb> shouldn't be linking to /usr/bin
[13:20] <Wes-> ashb: Really? It's broke for you too?
[13:20] <ashb> make install failed
[13:20] <Wes-> ashb: I normally suggest people create that by hand -- BUT -- that's vestigial
[13:20] <ashb> /usr/*local*/bin
[13:21] <ashb> Wes-: your link command for gsr looks wrong
[13:21] <Wes-> ashb: that was the impetus for #! env commonjs and the //gpsee: -ddzz stuff
[13:21] <ashb> -Wl,-install_name,/opt/local/gpsee/jsapi/lib/libmozjs.dylib \
[13:21] <ashb> you sohuldn't have that in there
[13:21] <Wes-> ashb: Hmm, good point, that must have gotten interherited from js-config
[13:22] <ashb> js-config is wrong in all sorts of ways
[13:22] <Wes-> ashb: js-config on mac is stoooopidly borken
[13:22] <Wes-> ashb: as for /usr/local/bin - it doesn't solve the problem of scripts that work everywhere; not everywhere has /usr/local/
[13:22] <Wes-> ashb: does gsr run though, besides that bad linking line?
[13:23] <ashb> that's what env is form :)
[13:23] <ashb> no - and i think it might be becuase of that link line
[13:23] <Wes-> ashb: Yes - and env doesn't pass options -- which is why I came up with the comment-embedded options
[13:23] <ashb> yeah
[13:23] <Wes-> ashb: would you mind re-making gsr, tweaking the line, and see what happens? (it works on Leopard)
[13:23] <Wes-> ashb: Good points, though -- I'm going to pull /usr/bin/gsr stuff before the 0.2 release
[13:24] <ashb> hmmm no love
[13:24] <ashb> can't find symbol _rc
[13:25] <ashb> and gpsee not showing up in otool -L
[13:25] <ashb> perhaps becasue libgpsee is linked wrong also
[13:25] <Wes-> ashb: *AH* I bet that's it
[13:26] <ashb> yeah!
[13:26] <Wes-> ashb: At least you're replicating nick's trouble case
[13:26] <ashb> okay so the first line output of otool -L is 'the link name to use'
[13:26] <ashb> compare and contrast:
[13:26] <ashb> http://pastie.org/864886
[13:27] <ashb> the first is compiled without -Wl,-install_name
[13:27] <Wes-> ashb: Thank you - I would not have solved this without your input
[13:28] <Wes-> ashb: I'm going to tweak the build system this morning; hopefully you'll be able to give me some quick feedback then? :)
[13:28] <ashb> if i recomiple libgpsee and gsr without the install_name
[13:28] <ashb> and run it via
[13:28] <ashb> DYLD_LIBRARY_PATH=. ./gsr
[13:28] <ashb> it works
[13:28] <ashb> (make install seemed to recompile even tho i manually compiled
[13:29] <Wes-> *sweet*
[13:29] <ashb> i..e your dependancies are a bit fruity
[13:29] <Wes-> Sort of -- each time you do an install I generate a version.o file
[13:29] <Wes-> this file embeds the current repository status, time of build, etc, so I can extract with ident
[13:30] <Wes-> means you relink on every install, which is kind of mean, but really helpful when a developer comes to you with a bug and has *no idea* what source code generated the embedding
[13:30] <Wes-> (yes that really happens, and often they are six months old)
[13:30] <ashb> true
[13:31] <Wes-> Okay -- I'm going to head into the office to fix that, thank you so much for helping me troubleshoot
[13:31] <ashb> Wes-: fwiw we dont use js-config ever
[13:31] <ashb> but cmake has stuff to search for things
[13:31] <ashb> at anyrate - just use it to get the paths
[13:31] <Wes-> ashb: I use it to avoid having a real build system. ;)
[13:31] <ashb> i'd noticed :)
[13:32] <ashb> so who was the guy who first repoted this issue?
[13:32] <ashb> he needs to learn more awesomeness skills
[13:32] <ashb> that or i need to find a way to captialize my skills better
[13:33] <ashb> i seem to have a knack for finding the root cause of problems quickly
[13:34] <ashb> Wes-: Homebrew: http://mxcl.github.com/homebrew/
[14:57] <Wes--> ashb: It was nickgsuperstar, the guy that does the "building spidermonkey" stuff
[14:57] <ashb> ah
[14:57] <Wes--> ashb: And even on Snow Leopard, I'm pretty I would have puzzled over that for a good horu
[14:58] <ashb> guess i knew cos i dug into it how the linker works for some reason
[14:59] <Wes--> Yeah. The darwin linker is a bit unusual. I don't mind it, though, except that it means more work. Wouldn't mind at all if everything adopted it.
[14:59] <ashb> this particualr bit isn't that unusual
[15:00] <ashb> linux has the exact same beahviour with -so-name
[15:00] <ashb> (the name you set via so-name at linke time is what will be searched for at runtime, no matter what the filename at link time was
[15:00] <Wes--> ashb: What changed here that broke me was that originally I was filtering out @executable_path/libmozjs.dylib from the LDFLAGS -- then I change the install_name of libmozjs
[15:00] <Wes--> I think -- firing up aquamacs now
[15:00] <ashb> which is a nice feature, unlil you want ot use relative includes via $ORIGIN
[15:01] <ashb> yeah i recal you mentioning you did that

 

 

Logs by date :