So, in short, you prepared an update for a port which is maintained
(by me) by just taking the newest release and checking that it compiles ?
It didn't occur to you that there might be a reason the port is *lagging*
by so much from the release ? like for instance, support for OpenBSD libraries
On Thu, Mar 18, 2010 at 09:07:48PM -0400, Daniel Dickman wrote:
- do you know if the shared libs issue been resolved?
Out of the box, 2.8.0 is not. I had a patch for 2.8.0 that *did* (or
rather, might) fix it, but then there were problems with them assuming
the linker does library chaining.
-
On Thu, Mar 18, 2010 at 09:07:48PM -0400, Daniel Dickman wrote:
Hi Michal, couple questions on this.
- any reason not to use 2.8.1 which was just released?
- do you know if the shared libs issue been resolved?
When I started, only 2.8.0 was available. Now I'm working with
2.8.1 and it looks
I prepare an update to cmake from version 2.4.8 to 2.8.0.
Please test this update for me. On x86 it builds without any problems.
CMake tends to be platform-independent, so I think, It should work on
different CPU architectures.
Hi Michal, couple questions on this.
- any reason not to use
On Fri, Mar 19, 2010 at 01:03:01AM +0100, Michal Radomski wrote:
I prepare an update to cmake from version 2.4.8 to 2.8.0.
huh? you removed cmake.port.mk. no way that can be right.
did you actually test this with anything in ports? there are at least
15 ports that use cmake. this probably
On Fri, Mar 19, 2010 at 01:15:22AM +, Jacob Meuser wrote:
On Fri, Mar 19, 2010 at 01:03:01AM +0100, Michal Radomski wrote:
huh? you removed cmake.port.mk. no way that can be right.
I've grep for 'cmake' and some ports use devel/cmake in 'MODULES'
variable. Is this connected with that
