[Libwebsockets] suggestion: Add include/libsockets.h link to build directory

Andy Green andy at warmcat.com
Tue Feb 28 01:00:26 CET 2017



On February 26, 2017 5:01:09 PM GMT+09:00, Andy Green <andy at warmcat.com> wrote:
>
>
>On February 26, 2017 3:48:50 PM GMT+09:00, Per Bothner
><per at bothner.com> wrote:
>>On 02/25/2017 06:43 PM, Andy Green wrote:
>>>
>>>
>>> On February 26, 2017 11:27:29 AM GMT+09:00, Per Bothner
>><per at bothner.com> wrote:
>>>> It would be helpful to be able to use the build directory
>"in-place"
>>>> i.e. after 'make' but without 'make install'.
>>>
>>> The main things that have led to it not being easy to use like that
>>are
>>>
>>>  - binding the .so at runtime is usually a matter of ldconfig and
>>/etc/ld.so.conf, implying copying the libs somewhere that's set up to
>>look at
>>
>>At least on GNU/Linux, you can specify LD_LIBRARY_PATH to link (at
>>run-time)
>>against non-system libraries.
>>
>>>  - the test apps want assets in a /usr/share type place set at
>>build-time
>>
>>DomTerm uses the "where am I" library
>>(https://github.com/gpakosz/whereami)
>>to find the executable, and uses ../lib or ../share relative to that.
>>I make a point of the DomTerm build directory being set up so
>>running-in-place
>>works teh asme way as after installation.
>
>The test apps are already too bloated with this and that (except
>test-server-v2.0.c shrank compared to the originals).
>
>>> I can imagine how to make the second fall back to looking at some
>../
>>dir also in build, but is your scheme going to be okay finding the
>libs
>>at runtime like that as well as link-time?
>>
>>Since libwebsockets also builds libwebsockets.a, I decided it
>>makes to use that, when building DomTerm against a non-installed
>>libwebsockets:
>
>I think static linking is a reasonable way if no system lws library.
>
>>if test "$with_libwebsockets" != "no"; then
>>   PKG_CHECK_MODULES(JSON_C, json-c)
>>   PKG_CHECK_MODULES(OPENSSL, openssl)
>>   case "${with_libwebsockets}" in
>>     "yes" | "")
>>       PKG_CHECK_MODULES(LIBWEBSOCKETS, libwebsockets)
>>       ;;
>>     *)
>>       #LIBWEBSOCKETS_LIBS="-L ${with_libwebsockets}/lib -lwebsockets"
>>       LIBWEBSOCKETS_LIBS="${with_libwebsockets}/lib/libwebsockets.a"
>>       LIBWEBSOCKETS_CFLAGS="-I${with_libwebsockets}/include"
>>       ;;
>>   esac
>>fi
>>
>>This assumes an include link as I suggested, though I could replace
>>setting LIBWEBSOCKETS_CFLAGS by:
>>   LIBWEBSOCKETS_CFLAGS="-I${with_libwebsockets}/../lib"
>>
>>for example.
>>
>>Using -I${with_libwebsockets}/include does seem more elegant though.
>
>I also met this myself the other day with ESP32, it expects a dir it
>can -I to bring in the public includes for all of its "components"... I
>hacked one into existence in the build dir dynamically, but actually
>having one in the source tree directly would also be cleaner there.

This can't be done in the source tree directly because we use lws_config.h that is created by cmake.

So I added a patch on CMakeLists.txt that creates ./include-ext/ in the build dir, with libwebsockets.h and lws_config copied in there by lws make action.

If you add a -I lws/build/include-ext or similar depending on your relative submodule layout, that should let you use the includes in-place.

-Andy

>-Andy
>_______________________________________________
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org
>https://libwebsockets.org/mailman/listinfo/libwebsockets



More information about the Libwebsockets mailing list