remove libuv from submodule, add pkg-config for libuv and generate dukluv.pc in pkg-config

[FreshXOpenSource]

For several reasons its handy to remove libuv from the submodules and rely on the system wide installed version of libuv (>=1.7) instead (i.e. upgrade path, usage in buildsystems such as buildroot etc...). For this i made a CMAKE patch which checks for libuv in the systems pkg-config and uses its flags. Furthermore we install a dukluv.pc file in the systems pkg-config so that we can easily be picked up by other build environments. Tested on MacOS X (brew based), RedHat EL7

$ rpm -i install /root/rpm/libuv-devel-1.9.1.testing.x86_64.rpm
$ cmake .
-- checking for module 'libuv>=1.7'
-- found libuv, version 1.9.1
-- Configuring done
-- Generating done
-- Build files have been written to: /root/dukluv-nouv

[goniz]

What about cross compiling? Wouldn't it be more difficult now?
The current state is almost perfect for cross compile..

[creationix]

@FreshXOpenSource I like having the submodule included and having the default build statically include libuv instead of link to a system version.

I'm fine for adding a compile option to use system libuv, but not to replace the default build.

[FreshXOpenSource]

a properly setup cross-compile environment such as buildroot or simple sysroot clones work fine with it (buildroot even better, that's our main motivation for this patch ;))

i will modify the patch so that dukluv is using compile time options and skips the uv submodule

[creationix]

@FreshXOpenSource I've never done a cross-compile so I have no opinion there. Also what are you using this project for?

I'm moving my efforts to https://github.com/nucleus-js/seaduk as it's design better fits my needs. I know duktape itself uses this for some stuff, but @svaarala has mentioned that he's willing to move to nucleus/seaduk if it ever replaces dukluv.

[FreshXOpenSource]

we embed a JS engine in the wally project https://github.com/FreshXOpenSource/wallyd https://github.com/FreshXOpenSource/wallyd. its an sdl2 based C project to provide a early video response on embedded systems with video out. to interact with the system (each texture should be programable with small JS snippets), we use dukluv. i will have a look at seaduk and see if we can easily switch.

On 26 Jul 2016, at 23:38, Tim Caswell notifications@github.com wrote:

@FreshXOpenSource https://github.com/FreshXOpenSource I've never done a cross-compile so I have no opinion there. Also what are you using this project for?

I'm moving my efforts to https://github.com/nucleus-js/seaduk https://github.com/nucleus-js/seaduk as it's design better fits my needs. I know duktape itself uses this for some stuff, but @svaarala https://github.com/svaarala has mentioned that he's willing to move to nucleus/seaduk if it ever replaces dukluv.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #29 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ACW5A9SEVIoIMSFVb__0D9AMepuIoHuxks5qZn5ngaJpZM4JVUtf.

[creationix]

nice stuff. You'll probably want me to split seaduk into two projects as it's a host application as well as libuv bindings. But the new bindings are a better design IMHO.

[FreshXOpenSource]

quickly looking at the code i guess we will be able to adapt to seaduk.

i guess the build process need to be adapted so that duktape and the uv-binding part can also be created as shared object libs. the main nucleus part should be adapted into our project such as it was in dukluv. i will look at it and in the best case submit a patch ;-)