Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38457/#review100721 --- Ship it! - Joris Van Remoortere On Sept. 21, 2015, 2:43 a.m., Alex Clemmer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/38457/ > --- > > (Updated Sept. 21, 2015, 2:43 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 > >
Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38457/#review99757 --- Ship it! Ship It! - Marco Massenzio On Sept. 21, 2015, 2:43 a.m., Alex Clemmer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/38457/ > --- > > (Updated Sept. 21, 2015, 2:43 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 > >
Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38457/ --- (Updated Sept. 21, 2015, 2:43 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 (updated) - 3rdparty/libprocess/3rdparty/CMakeLists.txt b9c9fae7d448906e9c9f5ab0ee3fe138a0171a7d Diff: https://reviews.apache.org/r/38457/diff/ Testing --- Thanks, Alex Clemmer
Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
> 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 > >
Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38457/#review99692 --- Patch looks great! Reviews applied: [38456, 38457] All tests passed. - Mesos ReviewBot 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 > >
Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
--- 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
Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38457/ --- (Updated Sept. 20, 2015, 1:25 a.m.) Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph Wu. 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 (updated) - 3rdparty/libprocess/3rdparty/CMakeLists.txt b9c9fae7d448906e9c9f5ab0ee3fe138a0171a7d Diff: https://reviews.apache.org/r/38457/diff/ Testing --- Thanks, Alex Clemmer
Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
> On Sept. 18, 2015, 9:10 p.m., Joseph Wu wrote:
> > You should consider adding a CMake macro to make this more maintainable.
> >
> > A macro that does something like:
> > ```
> > mkdir -p ${INPUT_SRC}-lib/lib
> > && cp -r ${INPUT_SRC}-build/lib/.libs/. ${INPUT_SRC}-lib/lib
> > ```
I actually think we shoudl re-evaluate whether to do this later. The commands
generated are different enough between libev and gmock that it's not clear we
gain anything by having a macro or function expand this out.
- Alex
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38457/#review99599
---
On Sept. 17, 2015, 10:03 a.m., Alex Clemmer wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38457/
> ---
>
> (Updated Sept. 17, 2015, 10:03 a.m.)
>
>
> Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph
> Wu.
>
>
> 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
> d13ba666740b4f2e382a0b1852724cfd519f8f64
>
> Diff: https://reviews.apache.org/r/38457/diff/
>
>
> Testing
> ---
>
>
> Thanks,
>
> Alex Clemmer
>
>
Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
> 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. 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. - Alex --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38457/#review99401 --- On Sept. 17, 2015, 10:03 a.m., Alex Clemmer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/38457/ > --- > > (Updated Sept. 17, 2015, 10:03 a.m.) > > > Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph > Wu. > > > 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 > d13ba666740b4f2e382a0b1852724cfd519f8f64 > > Diff: https://reviews.apache.org/r/38457/diff/ > > > Testing > --- > > > Thanks, > > Alex Clemmer > >
Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38457/#review99599
---
You should consider adding a CMake macro to make this more maintainable.
A macro that does something like:
```
mkdir -p ${INPUT_SRC}-lib/lib
&& cp -r ${INPUT_SRC}-build/lib/.libs/. ${INPUT_SRC}-lib/lib
```
3rdparty/libprocess/3rdparty/CMakeLists.txt (line 68)
This is more of a "see MESOS-3250" than a "MESOS-3250 will fix this" right?
(Can you reword a bit?)
3rdparty/libprocess/3rdparty/CMakeLists.txt (line 72)
Delete the ":" ?
- Joseph Wu
On Sept. 17, 2015, 3:03 a.m., Alex Clemmer wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38457/
> ---
>
> (Updated Sept. 17, 2015, 3:03 a.m.)
>
>
> Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph
> Wu.
>
>
> 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
> d13ba666740b4f2e382a0b1852724cfd519f8f64
>
> Diff: https://reviews.apache.org/r/38457/diff/
>
>
> Testing
> ---
>
>
> Thanks,
>
> Alex Clemmer
>
>
Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38457/#review99401 --- 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. - Marco Massenzio On Sept. 17, 2015, 10:03 a.m., Alex Clemmer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/38457/ > --- > > (Updated Sept. 17, 2015, 10:03 a.m.) > > > Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph > Wu. > > > 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 > d13ba666740b4f2e382a0b1852724cfd519f8f64 > > Diff: https://reviews.apache.org/r/38457/diff/ > > > Testing > --- > > > Thanks, > > Alex Clemmer > >
Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38457/#review99378 --- Patch looks great! Reviews applied: [38456, 38457] All tests passed. - Mesos ReviewBot On Sept. 17, 2015, 10:03 a.m., Alex Clemmer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/38457/ > --- > > (Updated Sept. 17, 2015, 10:03 a.m.) > > > Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph > Wu. > > > 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 > d13ba666740b4f2e382a0b1852724cfd519f8f64 > > Diff: https://reviews.apache.org/r/38457/diff/ > > > Testing > --- > > > Thanks, > > Alex Clemmer > >
Re: Review Request 38457: CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38457/ --- (Updated Sept. 17, 2015, 10:03 a.m.) Review request for mesos, Artem Harutyunyan, Joris Van Remoortere, and Joseph Wu. Summary (updated) - CMake: Fix MESOS-3250, a dynamic load error in Stout tests on OS X. 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 d13ba666740b4f2e382a0b1852724cfd519f8f64 Diff: https://reviews.apache.org/r/38457/diff/ Testing --- Thanks, Alex Clemmer
