On Sun, 18 May 2025 at 15:21, Timofei Zhakov <t...@chemodax.net> wrote:
> [...] > > >> I remember I had to do something with this in subversion. Let me dig down >> a little bit... >> > > In the current scenario the problem seems to be due to incorrect > installation of targets in cmake. Currently, the install is called with > custom bin and lib directories. However, apr modules are declared as MODULE > libraries [1] in cmake. The thing is the artifacts this kind of targets > work in a way so when install is called, the LIBRARY artifacts actually > include DLL files of the targets. See [2] and the fragment below: > > [[[ > ## Library Output Artifacts > > A library output artifact of a buildsystem target may be: > > - The loadable module file (e.g. .dll or .so) of a module library target > created by the add_library() command with the MODULE option. > ... > ]]] > > This means that when changing the LIBRARY property to `lib`, we actually > put DLL files into this directory, which is incorrect and causes the > problem. > > I'd like to suggest the following; First, there is already a macro for > declaring modules, so install invocation can be called from there directly, > using the correct destination path, instead of collecting a list of targets > to install. In this way we can set up the install properly and resolve the > issue. Then also a minor improvement in installation sequence can be done, > since it is required to call it a single time, only for the libaprutil-1 > target. > > This worked perfectly for me, and the cmake file seemed a little cleaner > after this work. See the patch attached to this email, which represents > those fixes. > > [1] > https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#module-libraries > [2] > https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#library-output-artifacts > > WDYT? > > Oops, my fault. I fixed it in the same way as in apr-trunk in r1925670. Thanks! -- Ivan Zhakov
