Menu
▾
▴
#41 CMake config?
I'm on a project making use of liblo and I noticed there's no cmake config available upstream. Are you interested in adding one to the library, then I might write it. This would make things a bit more convenient out of the box. pkg-config is fine actually for linux and mac, and linux is our primary platform anyways. But since it shall in principal also run on Windows I thought I just ask, then I would go ahead and write it up.
I realize there's pkg-config for windows as well, of course, but it seems kind of a pain to set it up.
We already have a working build system, and I feel it would be confusing to users to have two build systems in the main directory. However, CMake is often requested. Although I also don't want to have to maintain two build systems, but perhaps in the case of liblo it wouldn't be much work, since there aren't a lot of dependencies.
Do you know if it's possible to put the cmake system entirely in a subdirectory so that it's not confusing?
Hi, maybe I was not explicit enough in the request, let me try
that again. I'm not talking about switching your build system!
But in order to easily include liblo in CMake based projects,
it is possible to supply a kind of cmake config script, which
will set defines/lib/includepaths appropriately for the
(specific) liblo build, s.t. liblo can be used with a simple
find_package(liblo). There's also a pkg-config interface, which
I've been using on mac/linux, but setting this up on windows with
cygwin and everyting is a pain.
For the cmake module configs refer to:
Yes, people often want to replace tools that someone uses with their
favorite tools, however I'm not willing to accept that. I'd accept a
CMake-based build system, in parallel, kept in its own folder, and
then see how it goes. Otherwise I see little point in replacing a
working build system.
On Mon, Dec 14, 2015 at 10:51 AM, Patric Schmitz berzerka@users.sf.net wrote:
Related
Bugs: #41
Yup, I fully agree with you. Writing the mere config file will be
totally non-invasive to your current way of building things. I'm
halfway through having the cmake based liblo build ready however,
so will issue PR later and you might still have a look at it.
Otherwise I'd gladly provide just the module file as described.
This is not for me personally actually, but for someone
struggling with liblo inclusion on windows, so I thought I might
just go ahead and ask since this might be of use to more liblo users.
On 12/14/2015 03:19 PM, Stephen Sinclair wrote:
Sure, having the cmake config might be very useful indeed!
I definitely don't mind the idea of including it in a binary release,
so that Windows users can simply untar it and use liblo via cmake in
their projects.
I'll have a look at your PR when it's ready. (Easier to submit via
github these days..)
On Mon, Dec 14, 2015 at 11:24 AM, Patric Schmitz berzerka@users.sf.net wrote:
Related
Bugs: #41
Ok. So I made quite some progress.
The sourcetree builds fine for me using either gcc or g++,
version 5.2.0. For the latter I had to add a bunch of more
explicit casts, for the former a 'struct' was missing in 2 or 3
places for the cast-to-pointer-to-struct syntax. You can
comment/uncomment the set_source_files_properties in
CMakeLists.txt:31 in order to switch between them.
To build:
cd cmake
mkdir build ; cd build
cmake ..
make
There's no install target as of yet, just looking into it. Also
implying I haven't runtime tested it, but will do so shortly (I'm
at work so maybe it will have to wait till the evening).
It's best you look at the changes and tell me what you think. The
cmake build itself is short and concise for my taste, did not
expect it to go that smooth. Added those autoconf like test
macros for HAVE_POLL, HAVE_SELECT etc.
Now I'm dealing with getting the build to run on Windows, and I
noticed that, although there is HAVE_LIBPTHREAD and
ENABLE_THREADS, the latter seems to be used only for #ifdef'ing
pthreads related code. So I would suggest to merge the two in
order to avoid confusion. I have already done that here locally,
however I wonder: Do you actually depend on pthreads on Windows?
Did some minor fixes and adapted .gitignore to use pathes local
to the toplevel sourcetree (since it his my cmake/config.h.in),
but you will see that from the diffs.
So consider this work in progress still, I want to have it
runtime-tested on Linux and Windows before merge, for sure.
Oh yes, the repo lives at
No idea how to use sourceforge to issue PRs, but that'll do.
git://git.code.sf.net/u/berzerka/liblo
Hi, I was able to clone your repo and see your changes. Looks good so far, some path problems however, since I got,
/home/sinclairs/liblo/src/address.c:46:19: fatal error: lo/lo.h: No such file or directory
during "make", however running cmake from a build directory seemed to work well. As you infer, having those tests for HAVE... etc are important, so quite a bit of work over the years has gone into the configure script. There are also options to disable threading, run the tests, etc. To answer your question, yes, pthreads is used on Windows, if threads are supported. HAVE_LIBPTHREADS and ENABLE_THREADS are necessarily distinct, as the idea was to possibly support native Windows threading eventually, in which case HAVE_LIBPTHREADS could be false while ENABLE_THREADS could be true.
On 12/15/2015 03:27 PM, Stephen Sinclair wrote:
Can you post the compiler command line? In CMakeLists.txt:36 the
toplevel folder should be passed as an include directory,
relative to where CMakeLists.txt is located. Are you on Linux?
Ok. I will leave the tests out for the time being, if this is
only meant as a supplemental way of building, and you will stick
to autotools for the project, I suppose it is not that important
for now. Will add the ENABLE_THREADS then again and make it
configurable via the cmake config cache.
This is what I was guessing, will adapt accordingly. Thank you!
Aside: Since you mentioned it, are there plans to move the
project to GitHub eventually?
On Tue, Dec 15, 2015 at 11:50 AM, Patric Schmitz berzerka@users.sf.net wrote:
Ah, it's not a path problem, but rather that lo.h is not generated.
Trying building from a completely clean directory, you'll see that
lo.h doesn't exist. Normally lo/lo.h is built by autoconf from
lo/lo.h.in. This is mainly to avoid automatically including
lo/lo_serverthread.h when liblo is built without threading support.
Sounds good.
Actually I do most things on github. Technically I prefer having
discussions on the mailing list and doing PRs on github, from my repo,
http://github.com/radarsat1/liblo
However, I keep SourceForge as the main repository just because the
website is hosted there. I see no reason to move it for now.
Steve
Adapted, you might pull and retry. In order to be able to have a
BOOL cmake cache variable which can just be toggled/checked in
the curses and graphical frontends, I had to add a layer of
indirection. The cmake variable is named THREADING which will set
the value of ENABLE_THREADS if it is TRUE/ON/1/YES. I wanted to
omit the else branch in CMakeLists.txt to keep it minimal, so I
added that +0 construction in lo.h.in as not to have an empty
expression if it ENABLE_THREADS has not been set. Please tell me
if you are ok with having it like this, would prefer the else
branch in CMakeLists.txt, or see a more elegant way of doing it.
Ah! Then I will fork on github and issue PRs there in case of of
another contribution :) Yeah no need to move it.
Still at work, so no install target yet, but upcoming.
Hi, maybe I was not explicit enough in the request, let me try that again. I'm not talking about switching your build system! But in order to easily include liblo in CMake based projects, it is possible to supply a kind of cmake config script, which will set defines/lib/includepaths appropriately for the (specific) liblo build, s.t. liblo can be used with a simple find_package(liblo). There's also a pkg-config interface, which I've been using on mac/linux, but setting this up on windows with cygwin and everyting is a pain.
To answer the question about isolating the cmake build, there is only one file CMakeLists.txt required which typically resides at top level, however it would be no problem at all to put it into a cmake/ subfolder. If you are interested I could give writing a cmake based build a shot, then you get the config for inclusion in other cmake projects for free.
[sorry messed up editing post first time]
Last edit: Patric Schmitz 2015-12-14
Feel free to make a pull request then, and I'll take a look.
On Mon, Dec 14, 2015 at 10:32 AM, Patric Schmitz berzerka@users.sf.net wrote:
Related
Bugs: #41