On Fri, Oct 15, 2021 at 06:48:23PM -0400, Greg Troxel wrote:
> I think there is only one real bug, which is that cmake uses as RPATH in
> the build tree:
>
> BUILD_RPATH:/path/to/build/tree/lib
>
> when it should be doing
>
> /path/to/build/tree/lib:BUILD_RPATH
I agree it looks like a bug.
> On Oct 15, 2021, at 4:01 PM, Greg Troxel wrote:
>
>
> Paul Ramsey writes:
>
>> Let me know what happens on your system?
>
> The destdir has RPATH of the prefix, and the tests have RPATH of only
> the build tree. The tests all pass (which is good, because that's
> really what matters as
Paul Ramsey writes:
> Let me know what happens on your system?
The destdir has RPATH of the prefix, and the tests have RPATH of only
the build tree. The tests all pass (which is good, because that's
really what matters as the present discussion is about the test harness,
and not about the
Paul Ramsey writes:
> I'm running your script now, but just from looking at it, this seems
> suspicious...
>
> cmake .. \
>-DCMAKE_INSTALL_PREFIX=${PREFIX} \
>-DCMAKE_BUILD_RPATH=${LIBDIR} \
>-DCMAKE_INSTALL_RPATH=${LIBDIR}
>
> My understanding of the "build
So, I think dispensing with CMAKE_BUILD_RPATH while retaining
CMAKE_INSTALL_RPATH as you have it gives results that allow you to run your
script to completion cleanly... at least, I checked the output on MacOS, and
it's like this:
First using the current setup in your script. As you note in
I'm running your script now, but just from looking at it, this seems
suspicious...
cmake .. \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_RPATH=${LIBDIR} \
-DCMAKE_INSTALL_RPATH=${LIBDIR}
My understanding of the "build rpath" is that it exists in the built
tl;dr:
I've done things the cmake way and the test are still not ok.
The problem is that the test RPATH is being *appended* to the BUILD
RPATH, instead of prepended.
long version:
My build script is:
#!/bin/sh
if [ -d $HOME/bin/ccache ]; then
echo
There's a lot of new libraries and projects using cmake, even the venerable
gdal is heading that way, and that's a hard conversion. Talks in the postgres
world also swirl around that change. I think getting comfortable with it, takes
a while I know, is probably going to be more effecitive,
On Thu, Oct 14, 2021 at 10:02:03AM -0400, Greg Troxel wrote:
> Stepping back from just thinking about geos, in the context of a
> packaging system, there is a desire to do things in a way that works in
> the general case, rather than tightly adapating to particular systems.
Would a script like
Sandro Santilli writes:
> On Wed, Oct 13, 2021 at 03:41:30PM -0700, Paul Ramsey wrote:
>> Actually searching for "RPATH" here turns up all kinds of knobs if you want
>> different things done to rpath
>>
>> https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html
>
> Greg might be
I am guessing that this script is not doing anything to set RPATH and
that FreeBSD puts /usr/local/lib in the default linker path. Which is
interesting because people that build things not from ports might get
ports libraries linked without asking for that prefix - but that's a
system
Sandro Santilli writes:
> On Wed, Oct 13, 2021 at 12:08:50PM -0400, Greg Troxel wrote:
>>
>> Sandro Santilli writes:
>>
>> > What do you mean by "I like how our tests work now" ? How do they work
>> > for you ? Are them guaranteed to be using the *just_built* (rather
>> > than the
On Wed, Oct 13, 2021 at 03:41:30PM -0700, Paul Ramsey wrote:
> Actually searching for "RPATH" here turns up all kinds of knobs if you want
> different things done to rpath
>
> https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html
Greg might be after this:
Actually searching for "RPATH" here turns up all kinds of knobs if you want
different things done to rpath
https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html
P.
> On Oct 13, 2021, at 3:18 PM, Paul Ramsey wrote:
>
> Consider looking at cmake descriptions of what it intends to
Consider looking at cmake descriptions of what it intends to do with RPATH, and
ways to set link flags without forcing environment variables in
https://cmake.org/cmake/help/latest/variable/CMAKE_SHARED_LINKER_FLAGS.html
https://cmake.org/cmake/help/latest/variable/CMAKE_SKIP_INSTALL_RPATH.html
I should add, I'm using cmake version 3.16.3
--strk;
On Wed, Oct 13, 2021 at 11:31:54PM +0200, Sandro Santilli wrote:
> On Wed, Oct 13, 2021 at 12:08:50PM -0400, Greg Troxel wrote:
>
> > So maybe strk can test (on Linux I'm guessing):
>
> Ubuntu 20.10 here
>
> > build and install geos 3.9.1
On Wed, Oct 13, 2021 at 12:08:50PM -0400, Greg Troxel wrote:
> So maybe strk can test (on Linux I'm guessing):
Ubuntu 20.10 here
> build and install geos 3.9.1 as --prefix=/usr/foo
Done (3.9 branch of geos):
./autogen.sh && \
./configure --prefix=/tmp/geos && \
sudo make install
On Wed, Oct 13, 2021 at 12:08:50PM -0400, Greg Troxel wrote:
>
> Sandro Santilli writes:
>
> > What do you mean by "I like how our tests work now" ? How do they work
> > for you ? Are them guaranteed to be using the *just_built* (rather
> > than the *installed*) libraries ?
>
> I believe I've
Okay discussed with pramsey on IRC and I think I understand now why this is
all fine.
The lib ones are pointing at system installed, which is fine cause they
aren't used for testing.
The bin test_geos_unit (is pointing at libgeos_c.so.1 and libgeos.so.3.10.0)
so all tests will be going against
After all this talk decided to check Bessie (FreeBSD 64-bit) and I'm seeing
that the geos system installed is being hooked into the lib file, though the
test bin files at a glance look okay
The geos 3.9.1 on Bessie was installed using FreeBSD packaging
pkg install geos
and I see reference
> On Oct 13, 2021, at 9:12 AM, Greg Troxel wrote:
>
>
> Paul Ramsey writes:
>
>> That is the case on all the platforms we've had reported except
>> Gregs. Tests work against the libraries built in the build directory.
>
> I am not aware of a positive report for
>
> not Mac (which does
Paul Ramsey writes:
> That is the case on all the platforms we've had reported except
> Gregs. Tests work against the libraries built in the build directory.
I am not aware of a positive report for
not Mac (which does all of this stuff totally differently from normal Unix)
3.9 installed
Sandro Santilli writes:
> What do you mean by "I like how our tests work now" ? How do they work
> for you ? Are them guaranteed to be using the *just_built* (rather
> than the *installed*) libraries ?
I believe I've found a bug in running tests. When one passes in
-W,-R/usr/foo/lib to the
> On Oct 13, 2021, at 1:29 AM, Sandro Santilli wrote:
>
> On Tue, Oct 12, 2021 at 07:18:11PM -0700, Paul Ramsey wrote:
>
>>> The tests are written as if they are regular code; tests in general need
>>> to be marked for special linking. I don't see anything special there
>>> either.
>>
>> I
On Tue, Oct 12, 2021 at 07:18:11PM -0700, Paul Ramsey wrote:
> > The tests are written as if they are regular code; tests in general need
> > to be marked for special linking. I don't see anything special there
> > either.
>
> I don't know what you mean, but I also like how our tests work now
Thanks for taking the time to look closely, I have rolled some of the
easier notes in and saved others for the next major round.
On Mon, Oct 11, 2021 at 6:10 PM Greg Troxel wrote:
>
>
> As this is my first release using cmake I'm reading INSTALL etc. and
> have a few comments.
>
> 0) INSTALL
As this is my first release using cmake I'm reading INSTALL etc. and
have a few comments.
0) INSTALL says;
mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Release ..
Setting `CMAKE_BUILD_TYPE` to `Release` is necessary to enable compiler
optimizations.
but CMakeLists.txt says:
27 matches
Mail list logo
