Distributing cmake options in npm packages about cmake-js HOT 6 CLOSED

Did anything ever come of this? I'm currently trying to port an existing lib built with CMake and being able to use the build files almost as-is would be amazing...

edit: I'm currently trying to use nbind to target asm.js for in-browser usage

from cmake-js.

Also check out how autogypi finds nan:

import * as Promise from 'bluebird';
import * as resolve from 'resolve';

Promise.promisify(resolve)(
    dep, // A string, such as "nan".
    {
        basedir: basePath, // Root of the package that wants to find nan.
        packageFilter: (json: any) => {
            json.main = 'package.json';
            return(json);
        }
    }
).then((entry: string) => { /* entry is the path to package.json in nan root */ }

As long as the package that wants to find nan lists it as a dependency in its package.json, this should find it on both npm versions 2 and 3. It's not specific to nan, it'll add the root of any package to the include path unless there's a autogypi.json file in the root with custom instructions. I guess it could be changed to also support a custom block inside package.json.

In any case, I'd like cmake-js (or autogypi) to similarly find other packages besides nan and read additional compiler options or whatever else needs to go into CMakeLists.

from cmake-js.

That's how my boost-lib module works, it's a simple CMake include https://github.com/cmake-js/boost-lib#1-include. Of course it's not that fool proof, because it requires that boost-lib gotta get installed in the root node_modules folder. It's given with npm 3+ in almost 99.99% of cases. But if it's not, you can go with find_path, which will locate boost-lib in the depth of node_modules folders for sure. So the idea in CMake.js is that CMake is already a powerful build tool, we just don't need to invent its features in Node.

About you question at node-ffi. Please note that I'm working on an ffi module, that will fix the main issue of node-ffi, which is the performance. Or the lack of performance. You gotta pay with 100x+ overhead for its features and that's just not worth it. That's why I started my own module fastcall. With it you'll get almost the same performance (1.5-2x overhead at maximum) that you can have with yer shinny hand written C++ code but with 100% JavaScript. And fastcall is CMake based of course.

from cmake-js.

I see, that's really nice! So if some new app (not using C++ at all) depends on npm package foo, and foo then depends on boost-lib... Should foo use find_path in its CMakeLists? Is that more efficient than if cmake-js had a way for foo to announce its dependency so it could use known Node.js logic to find boost-lib?

And if so, why do you use JavaScript code to look for nan?

from cmake-js.

There could be many solutions for this problem. CMake.js uses JS code to find nan, because that was by hand on that time when I made that part of that code. Boost lib uses cmake, because I wanted to test if that could be a viable solution or doesn't.

Right now I believe the best solution would be:

• boost-lib index.js:

//...
exports.path =__dirname

• foo module's CMakeLists.txt:

EXEC_PROGRAM(node ${CMAKE_CURRENT_SOURCE_DIR}
        ARGS -p -e "require('boost-lib').path"
        OUTPUT_VARIABLE boostLibDirPath)
SET(CMAKE_MODULE_PATH  boostLibDirPath)
include(BoostLib)

I'm planning to improve both nan and boost-lib location strategies in the future.

from cmake-js.

It sounds like this was answered, and as nbind appears abandoned I dont see anything here that needs doing

from cmake-js.