On 3. 6. 25 21:00, Timofei Zhakov wrote:
>
> Hi again,
>
> I've tested it. Here is my feedback.
>
> Both apr-1 and apr-2 works perfectly on a Unix environment.
>
> However, again, dependency search is done in the wrong way on
Windows
> and may work incorrectly in some cases. In cmake, find_library()
> and find_path() are made so they handle all logic in relation to
where
> to look for each kind of artifact. They will handle system dirs,
> -DCMAKE_INSTALL_DIR, -DCMAKE_PREFIX_PATH, <MODULENAME>_ROOT
(APR_ROOT
> in this case),
Clearly, then, CMake's own FindOpenSSL.cmake is "doing it wrong",
because it uses OPENSSL_ROOT_DIR instead of OpenSSL_ROOT... ;)
I'm not sure, but I think they have changed it at some point and
currently both of them are supported, but one of them is sort of
"deprecated".
Also they call find_path() passing several additional paths including
one from the Windows Registry (which is quite weird),
Legacy. OpenSSL has a _long_ history of Windows ports, and I remember at
least two completely different ways to install it there. CMake/vcpkg is
a third. There was a time when it was "expected" that DLLs were somehow
registered, with configuration in the registry. I don't know the
details, but this is probably what they're doing.
but don't prevent standard library search (as I explained with
CMAKE_PREFIX_PATH and bla-bla-bla).
> and even cmake's environment variables, and I guess vcpkg also
> implements some custom things. This functionality is very useful
for
> people who need to set up their environments, to get builds against
> right libraries etc...
Ack
> I would like to suggest fix with the
serf-improve-apr-search.patch patch:
>
> [[[
> cmake: Improve search of APR and APR-Util libraries by
> calling find_library()
> and find_path() methods without passing PATH, since cmake could
> automatically
> determine it based on platform-dependent factors.
> ]]]
>
> After this patch, I got configuration successfully without
modifying
> settings on Windows which is good for now...
Actually, your patch basically does on Windows what we do on other
platforms, except that even there we handle *_ROOT ourselves. So it
looks like we'd actually have to merge a lot of if(SERF_WINDOWS)
branches into one generic search, which is good. I'll look into that
when I have a moment.
I'll just say that, when we first started writing CMakeLists.txt,
find_package in CMake 2 didn't do half the things it does now.
Oh, this makes sense...
Thanks for the patch! It pointed me in the right direction.
-- Brane
Can we actually remove the warning that cmake is an
experimental feature or not yet? I think as it is going to be
released, it should not be just an experimental build system but a
secondary one.
When we're actually satisfied with the way it works. Windows + Linux +
MacOS is 90+% of supported platforms, but there are others, oh yes;
where there might not even be a port of CMake. Also, right now,
SConstruct supports what we call "source layout" libraries, basically
where you built the dependency from sources and Serf would then just
look at the build tree, not the installed versions, to find the
libraries and headers.
This feature is probably irrelevant now that Windows is slowly, finally
joining the normal world when it comes to package management.
I made an addition to the patch, because I forgot to do the same thing
to locate the APR config executable. Updated patch is in the attachments.
And I tested it on both Windows and Unix platforms (config and manual
search).
By the way, I think we should rework it a bit so we will try config
first -- no matter whether the platform is unix like or not, and then,
if pkgconfig or apr-1-config weren't found, try manual search instead
(using find_path and find_library). because technically configs could
be also available on windows.
APR doesn't install pkg-config files on Windows (neither does Serf), and
it may or may not install apr_config{_version}.cmake there; this could
be specific to the vcpkg port.
For example, I think vcpkg does something in order to look for libs
through pkgconfig on win32, so this is the case.
Sure, if it looks for that automatically, then yes. Last I looked you
have to load a module for pkg-config support. Anyway, I think I know
where we're going with this, and it'll be easier now that I can test on
Windows (and Linux ... where FindBrotli.cmake is not the same as
FindBROTLI.cmake) before comitting.
-- Brane
