Re: [gpsee] Distro Challenges
2 views
Skip to first unread message
Wes Garland
Sep 20, 2011, 10:55:42 AM9/20/11
to gp...@googlegroups.com
On 20 September 2011 10:11, Jeff Johnson <n3...@mac.com> wrote:
Agree 100% -- that is the main impetus behind the GPSEE-0.3 on JS 1.8.5 fork. I am quite happy with the 1.8.2 performance, but not how it is packaged.
We also need to get OS Distros to standardize how JS 1.8.5 is configured. I have been suggesting js-ctypes, threadsafe, system NSPR. I know that's how Ubuntu is shipping, but not everybody (glandium? walters?) is turning on js-ctypes IIRC. [GPSEE doesn't need js-ctypes, but it will work if enabled]
We should also link GPSEE against the system LibFFI rather than building our own. No biggie, provided it's 3.0.8 or better.
Aside, since I know you are on PPC: Cameron Kaiser of 10-4 Fox has posted patches for a complete JIT that should work with JS 1.8.5. It's my intention to release libmozjs185-1.0.1 which incorporates that and a few other bugfixes (no API changes) around the same time as I stamp GPSEE 0.3. You can see where I'm headed for that release by watching the wanted-standalone-js flag in the whiteboard on bugzilla.mozilla.org.
Geez. You are absolutely 100% correct. Wow. I have been missing the forest for the trees on that one.
Although, we don't want talk about packages yet as they have a specific meaning in CommonJS and we don't support them ATM. We'll talk about modules, and modules can either be .js or .so files (.dylib on Darwin), or both.
CommonJS hasn't really specified any of this stuff, I think we should just take "first to publish" approach and let others follow.
The default GPSEE module path could then be:
${prefix}/lib/gpsee/modules
${prefix}/lib/gpsee/site-modules
${prefix}/lib/commonjs/modules
${prefix}/lib/commonjs/site-modules
So then we'd have
- ${prefix}/lib/gpsee/libgpsee.so
- ${prefix}/lib/libmozjs-185.so.1.0.0 (provided externally)
- ${prefix}/include/gpsee/*.h
- ${prefix}/bin/gsr
- ${prefix}/lib/pkgconfig/gpsee.pc
Where do we install gpsee-config, and gpsee_precompiler?
gpsee-config is used by 3rd party build systems to query GPSEE's configuration.
gpsee_precompiler is used by 3rd party build systems to generate compiled byte-code during "make install"; it also checks for errors and exits with an error condition, letting the 3rd party build system halt its make when the installed JS won't run (i.e. syntax error).
We would also reserve ${prefix}/commonjs/packages + site-packages, and search for CommonJS packages when something like Christoph's PINF loader is able to make them available.
What do you think, Jeff? I could totally live with something like that.
Wes
-- The critical path (imho) to a GPSEE release is going to be
uncoupling -ljs so that JS and GPSEE can be separately distributed.
Agree 100% -- that is the main impetus behind the GPSEE-0.3 on JS 1.8.5 fork. I am quite happy with the 1.8.2 performance, but not how it is packaged.
We also need to get OS Distros to standardize how JS 1.8.5 is configured. I have been suggesting js-ctypes, threadsafe, system NSPR. I know that's how Ubuntu is shipping, but not everybody (glandium? walters?) is turning on js-ctypes IIRC. [GPSEE doesn't need js-ctypes, but it will work if enabled]
We should also link GPSEE against the system LibFFI rather than building our own. No biggie, provided it's 3.0.8 or better.
Aside, since I know you are on PPC: Cameron Kaiser of 10-4 Fox has posted patches for a complete JIT that should work with JS 1.8.5. It's my intention to release libmozjs185-1.0.1 which incorporates that and a few other bugfixes (no API changes) around the same time as I stamp GPSEE 0.3. You can see where I'm headed for that release by watching the wanted-standalone-js flag in the whiteboard on bugzilla.mozilla.org.
I believe that for "server JS" to be successfully deployed, then some
directory hierarchy like (for python) ${prefix}/lib*/python*/site-packages
needs to be attempted. WIthout some clarity on the conventions,
then its tricky to extend an interpreted language.
Geez. You are absolutely 100% correct. Wow. I have been missing the forest for the trees on that one.
Although, we don't want talk about packages yet as they have a specific meaning in CommonJS and we don't support them ATM. We'll talk about modules, and modules can either be .js or .so files (.dylib on Darwin), or both.
CommonJS hasn't really specified any of this stuff, I think we should just take "first to publish" approach and let others follow.
The default GPSEE module path could then be:
${prefix}/lib/gpsee/modules
${prefix}/lib/gpsee/site-modules
${prefix}/lib/commonjs/modules
${prefix}/lib/commonjs/site-modules
So then we'd have
- ${prefix}/lib/gpsee/libgpsee.so
- ${prefix}/lib/libmozjs-185.so.1.0.0 (provided externally)
- ${prefix}/include/gpsee/*.h
- ${prefix}/bin/gsr
- ${prefix}/lib/pkgconfig/gpsee.pc
Where do we install gpsee-config, and gpsee_precompiler?
gpsee-config is used by 3rd party build systems to query GPSEE's configuration.
gpsee_precompiler is used by 3rd party build systems to generate compiled byte-code during "make install"; it also checks for errors and exits with an error condition, letting the 3rd party build system halt its make when the installed JS won't run (i.e. syntax error).
We would also reserve ${prefix}/commonjs/packages + site-packages, and search for CommonJS packages when something like Christoph's PINF loader is able to make them available.
What do you think, Jeff? I could totally live with something like that.
Wes
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Reply all
Reply to author
Forward
0 new messages