mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marco Massenzio" <ma...@mesosphere.io>
Subject Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
Date Sun, 20 Sep 2015 04:06:31 GMT


> On Sept. 17, 2015, 4:44 p.m., Marco Massenzio wrote:
> > I'm excited about this!
> > Tested on OSX and (at least, as far as stout_tests go, it works, yay!)
> > 
> > A quick question: why, instead of moving the files, we don't simply add a symlink
that will "look right" to the linker etc.
> > (this may be an exceedingly dumb question, due to my extremely limited understanding
of the build system)
> > 
> > Thanks, Alex, for doing this - can't wait to bid farewell to CDT for good.
> 
> Alex Clemmer wrote:
>     I don't know that there's a particular reason to _not_ use a symlink, but the reasons
I went with a hard copy are:
>     
>     (1) It's not clear that it was easier or cleaner to symlink.
>     (2) Every other install command does a hard copy and it might lead to weird problems
if we're not consistent.
>     (3) Not 100% sure about the differences between Windows and Linux symlinks, and it's
better to be safe than sorry.
>     
>     Would love to hear from you if you think these are not good reasons, as I actually
(in spite of how it may appear) basically have no idea what I'm doing.

(1) it is probably "cleaner" to the extent you only have a copy of the actual files - everything
else points to that "source of truth"
(while I type this, I realize that in the era of 5TB for < 100 bucks HDs, I sound like
my great-granpa :)

(2) I have my own opinion about consistency... (I totally know you'll love it: I did when
I was at G)
http://despair.com/collections/demotivators/products/consistency

(3) You're on your own there - I only found out Windows had symlinks last year (and I only
found out because they didn't work the way one expected them to :)

In general, I prefer *soft* links (`ln -s`) in Linux as they are fast and inexpensive and
easy to manage - copying files always leaves me with the worry the copies will go out of sync.

But #3 seems like a winner in the argument.

For now, I'd say, let's go with copies - let's get it to a "known good state" where it all
works, then we can tinker with it to our heart's content later on and optimize it, if need
be.

Thanks!


- Marco


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38457/#review99401
-----------------------------------------------------------


On Sept. 20, 2015, 2:03 a.m., Alex Clemmer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38457/
> -----------------------------------------------------------
> 
> (Updated Sept. 20, 2015, 2:03 a.m.)
> 
> 
> Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph Wu.
> 
> 
> Bugs: MESOS-3250
>     https://issues.apache.org/jira/browse/MESOS-3250
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> A few third-party libraries (libev, gmock) do not have `make install`
> commands available, so below we have to add our own "install" commands.
> 
> The reason is: if we do not, we get runtime library load problems on OS
> X. In particular, `dydl` will look for these libraries at the prefix we
> passed to `configure` (or in `/usr/local` if we did not pass a prefix
> in), but since they don't have a `make install` step, they never get
> placed in the prefix folder.
> 
> Our solution is to:
>   (1) make a lib directory inside the Mesos folder for each of the
>       libraries that has no install step, and
>   (2) copy all such libraries into their respective directories.
> 
> (Note that step (1) is not only convenient, but important: make will add
> a `lib` to the end of your prefix path when linking, and since the built
> libraries end up in a `.libs` folder, it's not enough to simply pass the
> build directory into `configure` as a prefix; so if we're going to move
> the libraries, we might as well move them to a library folder.)
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/CMakeLists.txt b9c9fae7d448906e9c9f5ab0ee3fe138a0171a7d

> 
> Diff: https://reviews.apache.org/r/38457/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message