Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merges node-osrm into repo. #3768

Merged
merged 10 commits into from
Mar 21, 2017
Merged

Merges node-osrm into repo. #3768

merged 10 commits into from
Mar 21, 2017

Conversation

daniel-j-h
Copy link
Member

@daniel-j-h daniel-j-h commented Mar 2, 2017

Merging node-osrm NodeJS bindings into the repository. Can be built with

cmake .. -DENABLE_NODE_BINDINGS=On

Structured as follows

  • src/bindings/node - recursive CMakeLists.txt and binding impl.
  • include/bindings/node - binding headers

What's still missing

  • copy tbb libs to lib/bindings or use static tbb libs only for the node bindings (?)
  • binary publishing / caching, node-pre-gyp can we do this without the need for a Makefile?
  • tests
  • docs
  • cmake depends on npm install for node-cmake - should cmake do this on the fly?
  • hook up to travis
  • merge tests, only keep Berlin dataset, discard Monaco and adapt all tests
  • let travis build and publish binaries

@daniel-j-h daniel-j-h requested a review from TheMarex March 2, 2017 12:08
@daniel-j-h daniel-j-h force-pushed the merge-node-osrm branch 3 times, most recently from ba29a24 to 6e130b6 Compare March 2, 2017 15:59
@@ -0,0 +1,32 @@
OSRM_RELEASE:=$(shell node -e "console.log(require('../../../../package.json').osrm_release)")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should replace the test data for test/data in the root directory with berlin from these tests and then reuse it here instead of having an own test dataset.

Copy link
Member Author

@daniel-j-h daniel-j-h Mar 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, requires changing all coordinates from locations in Monaco to Berlin - I agree having multiple datasets is ugly.

@@ -0,0 +1,507 @@
#include "osrm/engine_config.hpp"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: I would prefer a less deep filesystem structure like: src/node instead of src/bindings/node purely because I don't like typing so much :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was me being sneaky and opening up the door for more bindings :)

Also give https://github.com/junegunn/fzf a try (or ctrl+p)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah but you can also have src/python if you want that. I don't think we will have namespace conflicts 😉


"nan": "^2.1.0",
"node-cmake": "^1.2.1",
"node-pre-gyp": "~0.6.30"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This package.json needs an install and preinstall target like here:

https://github.com/Project-OSRM/node-osrm/blob/master/package.json#L45-L47

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@daniel-j-h daniel-j-h force-pushed the merge-node-osrm branch 2 times, most recently from b2ac9dc to 09a7273 Compare March 6, 2017 14:41
@TheMarex
Copy link
Member

TheMarex commented Mar 6, 2017

cmake depends on npm install for node-cmake - should cmake do this on the fly?

@daniel-j-h Hm, would it be possible to bundle the cmake script directly? That is what the v2 docs recommend as well: https://github.com/cjntaylor/node-cmake

@daniel-j-h
Copy link
Member Author

Yes, can do. Vendoring in the cmake dir.

@daniel-j-h daniel-j-h force-pushed the merge-node-osrm branch 2 times, most recently from e71cc1b to 15d1474 Compare March 7, 2017 14:28
@daniel-j-h
Copy link
Member Author

Merged node-osrm tests into backend; the Monaco dataset is gone now. Important: I kept the s3 files for backwards compat. and uploaded the Berlin ones and made them public.

Had to adapt all tests, but now it works. The Tile plugin is especially fragile in that regard, and caused some pain. In the end I got it working (e.g. with range checks for sizes).

The tile in Berlin does not seem to have strings in it for street names - any insights here @danpat? Should all tiles have the street names in them for streets they display?

Refs.

@daniel-j-h
Copy link
Member Author

Having LTO builds enabled for this repo.'s release / production builds is a blocker for merging this PR: #3770

Also this is mostly done with the exception of

  • the Tile plugin behavior outlined above
  • publishing binaries via node-pre-gyp, I'm missing some context how to set this up and test the full pipeline without publishing artifacts to npm while doing so. cc @TheMarex

@TheMarex
Copy link
Member

TheMarex commented Mar 8, 2017

publishing binaries via node-pre-gyp, I'm missing some context how to set this up and test the full pipeline without publishing artifacts to npm while doing so. cc @TheMarex

node-pre-gyp does not publish packages to npm, that is a manual step you would need to do. To just test binary builds try the following:

  1. Make sure https://github.com/Project-OSRM/node-osrm/blob/master/scripts/publish.sh is run at the end of the travis build
  2. Change version in the package.json to something new like 5.7.0-daniel
  3. Commit this with [publish binary] Test version of 5.7.0 for Daniel
  4. ????
  5. Profit.

@danpat
Copy link
Member

danpat commented Mar 8, 2017

@daniel-j-h yes - there should be street name attributes for any visible street on the tile:

#2488

We're not rendering those labels on the debug frontend though - are you sure they're missing from the tiles?

@TheMarex
Copy link
Member

What is blocking here? I would like to get this merged in time to integrate the algorithm selection in node-osrm and add new MLD toolchain.

@daniel-j-h
Copy link
Member Author

daniel-j-h commented Mar 17, 2017

Here's an update:

Otherwise building the binaries is hooked up now via node-pre-gyp.

@TheMarex
Copy link
Member

Check headers failing for nan https://travis-ci.org/Project-OSRM/osrm-backend/jobs/212117115#L2521

You can either exclude the bindings from the header check or make the compile unit for it a fake node module.

gcc debug builds are timing out on travis, looks unrelated but is a pita
clang 4 linker error https://travis-ci.org/Project-OSRM/osrm-backend/jobs/212117117#L4487-L4496, also looks unrelated

Did you try rebasing on master?

@daniel-j-h
Copy link
Member Author

Good catch - seems like the build and publish scripts were triggering a second build. I guarded them now behind the ENABLE_NODE_BINDINGS env var. Let's see how this works.

.travis.yml Outdated
@@ -173,7 +173,7 @@ install:
- export OSRM_BUILD_DIR="$(pwd)/build-osrm"
- mkdir ${OSRM_BUILD_DIR} && pushd ${OSRM_BUILD_DIR}
- export CC=${CCOMPILER} CXX=${CXXCOMPILER}
- cmake .. -DCMAKE_BUILD_TYPE=${BUILD_TYPE} -DENABLE_MASON=${ENABLE_MASON:-OFF} -DENABLE_ASSERTIONS=${ENABLE_ASSERTIONS:-OFF} -DBUILD_SHARED_LIBS=${BUILD_SHARED_LIBS:-OFF} -DENABLE_COVERAGE=${ENABLE_COVERAGE:-OFF} -DENABLE_SANITIZER=${ENABLE_SANITIZER:-OFF} -DBUILD_TOOLS=ON -DENABLE_CCACHE=ON
- cmake .. -DCMAKE_BUILD_TYPE=${BUILD_TYPE} -DENABLE_MASON=${ENABLE_MASON:-OFF} -DENABLE_ASSERTIONS=${ENABLE_ASSERTIONS:-OFF} -DBUILD_SHARED_LIBS=${BUILD_SHARED_LIBS:-OFF} -DENABLE_COVERAGE=${ENABLE_COVERAGE:-OFF} -DENABLE_SANITIZER=${ENABLE_SANITIZER:-OFF} -DBUILD_TOOLS=ON -DENABLE_CCACHE=ON -DENABLE_NODE_BINDINGS=${ENABLE_NODE_BINDINGS}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs to be -DENABLE_NODE_BINDINGS=${ENABLE_NODE_BINDINGS:-OFF}.

@TheMarex
Copy link
Member

Fixed the windows install and data preparation and disabled the ASAN option for the GCC build for now.

We need to switch the dataset back to Monaco, Berlin is too big for CI (contracting it takes ages in debug mode and makes our builds time out).

Hopefully this will work and we can merge this to unblock #3846.

@daniel-j-h daniel-j-h force-pushed the merge-node-osrm branch 3 times, most recently from c2a959f to cfa4e5f Compare March 21, 2017 13:19
@daniel-j-h
Copy link
Member Author

Travis green! Beware, we are not yet running the NodeJs tests (tests need to be adapted to Monaco now that I changed it back from the Berlin dataset), and we have to enable coverage again.

@oxidase
Copy link
Contributor

oxidase commented Mar 21, 2017

[00:12:32] > [email protected] install C:\projects\osrm
[00:12:32] > node-pre-gyp install --fallback-to-build=false
[00:12:32] 
[00:12:32] node-pre-gyp ERR! install error 
[00:12:32] node-pre-gyp ERR! stack Error: 403 status code downloading tarball https://mapbox-node-binary.s3.amazonaws.com/osrm/v5.7.0/Release/node-v48-win32-ia32.tar.gz

is there any chance to get for win32? Otherwise npm testing should be commented in appveyor.yml

@TheMarex
Copy link
Member

Hrm I'm not sure why npm even tries to run node-pre-gyp on Windows. I thought this was disabled with decf222#diff-180360612c6b8c4ed830919bbb4dd459R26

@TheMarex
Copy link
Member

Remaining issue with the tests ticketed here #3851 Merging to unblock #3834

@TheMarex TheMarex merged commit bfc272f into master Mar 21, 2017
@TheMarex TheMarex deleted the merge-node-osrm branch March 21, 2017 20:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants