search

cappuccino / cappuccino

Web Application Framework in JavaScript and Objective-J
https://cappuccino.dev/
GNU Lesser General Public License v2.1
2.2k stars 333 forks source link

Error building JavaScriptCore engine on Mojave beta #2742

Closed enquora closed 5 years ago

enquora commented 5 years ago

Is this a problem with 32-bit linking no longer supported? console output

enquora commented 5 years ago

Confirmed - Xcode 10 doesn't provide 32-bit standard libraries and narwhal-jsc Makefile specifies i386 rather than x86_64 architecture.

mrcarlberg commented 5 years ago

Have you tried to just change the Makefiles so it specifies x86_64 architecture instead?

enquora commented 5 years ago

I have - it wasn't sufficient. There are multiple problems - the standard library(s) have been renamed in Xcode 10 and the Makefile uses a single definition for both C and CPP flags but this seems to no longer work with the library renaming. More work required.

cappbot commented 5 years ago

Milestone: Someday. Label: #new. What's next? A reviewer should examine this issue.

enquora commented 5 years ago

There is also a linker failure - libstc++ isn't included with Xcode 10 and libc++ must be used. Continuing to modernize the Makefile(s)

enquora commented 5 years ago

It looks as though I have it compiling using the following changes:

After making these changes, executing make in narwhal/packages/narwhal-jsc produces warnings but no errors.

Functionality not yet tested.

Can we live with macOS 10.9 as a minimum deployment target?

daboe01 commented 5 years ago

=macOS 10.9 is no issue for me

enquora commented 5 years ago

narwhal-jsc is confirmed compiling using both Xcode 9 and Xcode 10 now - although I have yet to test extensively in actual usage.

An oddity in ./bootstrap.sh for the Cappuccino source - a --copy-local: option exists to use a local copy of cappuccino-base, which is ideal for testing and development. Unfortunately, it expects the local copy to be a zip archive which adds significant friction when testing.

It makes more sense to specify a source directory and copy it. The bin directory of cappuccino-base contains some symlinks — which are nuisance to handle with cp -rf. Since ./bootstrap.sh is a bash file, is there any reason to not assume a 'nix system and use rsync to copy the local version of cappuccino-base?

I'd like to package this up as patches in a day or so and have people test it in their own environments.

mrcarlberg commented 5 years ago

We can live with macOS 10.9 as a minimum deployment target

mrcarlberg commented 5 years ago

Most people uses 'nix systems but we would like to be able to run on a Windows machines in the future. If rsync will not make that harder it is ok to use that.

enquora commented 5 years ago

A javascript-only toolchain eliminates this problem. Using rsync is only a quick fix for testing the existing bootstrap process. The --copy-local: implementation doesn't make sense to me in any context, but I'll leave it in place and add an rsync-based option.

If we're using an entirely node-based toolchain, the process for sourcing a local cappuccino-base during the bootstrap process can be implemented in javascript. Shell-like utility libraries exist already in npm - but I have a a strong antipathy to npm and believe using packages managed by it are an invitation to disaster. It will take a little longer to write something without promiscuous external dependencies but is certainly feasible.

enquora commented 5 years ago

Testing required.

Updates made to cappuccino/cappuccino and cappuccino/cappuccino-base:

cappuccino:

to test: ./bootstrap.sh --rsync-base /path/to/local/copy/of/updated/cappuccino-base

commits/patches for testing: https://github.com/enquora/cappuccino/commit/91bf164344db1ec1765eba0b96cff76afe4b9019 https://github.com/enquora/cappuccino-base/commit/8ee79491fe285b5b46e067c8d244e305ee06e204

kerusan commented 5 years ago

I get errors when testing on Mojave, When building with --rsync, building narwhal-jsc fails with: *** No rule to make target `deps/libedit-20180525-3.1', needed by 'deps/libedit-20180525-3.1/src/.libs/libedit.dylib'. Stop. Is there something missing or is it a path error?

enquora commented 5 years ago

Can you run 'make' in the libedit source directory and report if it compiles or not? I'll take a look again through the entire bootstrap process. It's easy to make a mistake in a non-trivial bash script

kerusan commented 5 years ago

Really don't know if I get you right. I downloaded your cappuccino-base and in your master branch I see that you have removed packages/narwhal-jsc/deps/libedit-20100424-3.0 (commit 1b1ec39) but I don't see that you have the new version: packages/narwhal-jsc/deps/libedit-20180525-3.1. Do I need to put that one in by myself? or is there a commit missing?

kerusan commented 5 years ago

Also the command ./bootstrap.sh --rsync-base /path/to/local/copy/of/updated/cappuccino-base needs a / in the end like ./bootstrap.sh --rsync-base /path/to/local/copy/of/updated/cappuccino-base/

kerusan commented 5 years ago

also the reference to the commit enquora@f00a5fb is about tableview header, it should be the updated rsync commit instead or?

kerusan commented 5 years ago

Still only a removal of the version libedit-20100424-3.0 and no libedit-20180525-3.1 in the commits.

enquora commented 5 years ago

@kerusan

The cappuccino-base commit should be ok now. Don't forget the training slash on the path to your local copy of cappuccino-base when you use the --rsync-base option.

I've removed the patches - they can be retrieved by simply appending .patch to the commit URL

The cappuccino bootstrap.sh commit remains the same.

kerusan commented 5 years ago

Ok I have now tested a bit with the new libedit on place and now it seems to work fine on Mojave.

daboe01 commented 5 years ago

@enquora are you ready for a pull request?

enquora commented 5 years ago

@daboe01 afaik this was resolved in 1.0 with a patch from myself and @aljungberg . I will confirm this weekend so we can close this.

enquora commented 5 years ago

Works fine.