Closed moodyhunter closed 2 years ago
@stefanofiorentino it looks good to me but could you review it too? I'm far from being a cmake expert, so two extra eyes can help here. 😅
I’ll check it later this week.
Change request: I would spin-off the conan-related commit in an other PR.
I'm fine with the request from @stefanofiorentino I don't have a strong opinion here, so I follow him. 🙂
Hi all, I've just force pushed and removed that conanfile
related commit from the git log, for now, it should be clean and only contains a single commit.
@skypjack should we put this into an experimental branch and let us time to be tried by someone else?
I agree, I deleted my fork by accident :( , it'll be better if an experimental branch can be created, this also allows more people to test the changes.
Makes sense. I would update uvw
to wrap libuv
v1.42 though, then we can create a branch from the last version.
It seems that a dl
library is missing, (See https://github.com/moodyhunter/QvPersonal/runs/3201566023?check_suite_focus=true#step:8:273 and https://github.com/skypjack/uvw/blob/master/src/CMakeLists.txt#L80) however the fork is deleted and I can't update this PR.
It seems that a
dl
library is missing, (See https://github.com/moodyhunter/QvPersonal/runs/3201566023?check_suite_focus=true#step:8:273 and https://github.com/skypjack/uvw/blob/master/src/CMakeLists.txt#L80) however the fork is deleted and I can't update this PR.
This dependency comes from libuv
(and that's the only one IIRC), as they have API regarding the management of shared libraries.
Now, is it uvw
responsibility to link under-the-hood to dl
or is better to leave it to-do
to the final linker?
That's a matter of taste and philosophy up-to-me.
So I guess @skypjack has to be invoked to the final decision: uvw
users would link to dl
implicitly or explicitly?
I'd make users link it explicitly. dl
isn't a direct dependency of uvw
. Instead, it's a dependency of the underlying library.
As an user, I wouldn't feel comfortable with an indirect dependency pulled in by a third party library honestly.
I'd make users link it explicitly.
dl
isn't a direct dependency ofuvw
. Instead, it's a dependency of the underlying library. As an user, I wouldn't feel comfortable with an indirect dependency pulled in by a third party library honestly.
I like when the linker breaks and I discover hidden dependencies. I feel the developers are playing fair with me. So we agreed.
Ciao, I've committed some more modifications to this PR here: experimental. As already stated somewhere, this additions will encapsulate the right version of libuv in the uvw subfolder of system folders during installation. This avoid system folders pollution/overwriting. I guess that's the best we can achieve up to now. Do you agree?
@moodyhunter could you please try this and see if it finally solve your issue? https://github.com/skypjack/uvw/tree/experimental Long story short: the installation phase of the dependent libuv is done in the uvw subfolder.
Yeah, it seems to be good, all header-only, shared and static libraries are properly installed now.
@stefanofiorentino I would merge this upstream. Any objection?
No, I certainly agree.
@stefanofiorentino I would merge this upstream. Any objection?
Let's proceed with this. I mean upstream
is to me your repo as my origin
is my fork.
Anyway I think we will get it to master too, right? That's ok to me.
CMake package config files for uvw, they are now installed as ${LIBDIR}/cmake/uvw/uvwConfig.cmake with target files for appropriate configuration (e.g. debug, release, etc...).
A
uvw::uvw
ALIAS target is created for uvw static library, to make persistency with what is done to the header-only version,Callers can now use
find_package(uvw)
and link with theuvw::uvw
target to use uvw in their projects directly using CMake.