arrow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suvayu Ali <fatkasuvayu+li...@gmail.com>
Subject Re: CMake refactor Heads-up
Date Sat, 16 Mar 2019 17:01:16 GMT
Hi Uwe,

On Sat, Mar 16, 2019 at 04:31:32PM +0100, Uwe L. Korn wrote:
> 
> > 2. I don't know if this is intentional, but jemalloc and rapidjson aren't detected
on my system.
> > 
> 
> Not sure if it is detected or not as this is missing from the log above. That log lists
only the bundled versions that would be installed if the package is not found on your system.
Whether or not system RapidJSON is used will be logged some lines later. 

Indeed, I misunderstood the log.  I think here's the relevant part:

  -- Building (vendored) jemalloc from source
  -- RapidJSON found. Headers: /usr/include

> For jemalloc the situation is slightly different. We have vendored upstream's head of
the 4.x branch as that was until some time ago the only version that worked reliably on all
systems together with Arrow. We could have a look again at using the newest jemalloc version
again.

Okay.

> > 3. There does not seem to be an uninstall target.
> 
> CMake doesn't provide this and their FAQ https://gitlab.kitware.com/cmake/community/wikis/FAQ#can-i-do-make-uninstall-with-cmake
sounds reasonable to me. I guess package managers are better at removing Arrow again than
our CMake scripts. Especially as we would only be aware of the currently build files and not
the ones of previous versions. For example current master builds libarrow.so.13 but is not
aware of the libarrow.so.12 of previous releases.

I guess I felt the need as I was first experimenting with building from source before I tried
building an RPM.  But given there is a simple oneline workaround, it's manageable.

> > 4. AFAIU, the pyarrow build expects the libraries in $CMAKE_INSTALL_PREFIX/lib.
 This will never be accepted by a distro.  I do realise this one is probably hard to resolve,
given how the builds are setup at the moment.
> 
> This should be resolvable. One of the odeas of the recent refractor was to get rid of
so hard assumptions. We need to carry this on also on the Python side. Can you open a JIRA
with a link to the code that makes this assumption?

It's a bit late here, I'll try to do that tomorrow and report back :).

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Mime
View raw message