You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@mesos.apache.org by Alex Clemmer <cl...@gmail.com> on 2015/09/17 12:03:36 UTC
Review Request 38457: CMake: Fix MESOS-3250,
a dynamic load in Stout tests on OS X.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/38457/
-----------------------------------------------------------
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 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.
Posted by Alex Clemmer <cl...@gmail.com>.
> 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.
Posted by Joseph Wu <jo...@mesosphere.io>.
-----------------------------------------------------------
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)
<https://reviews.apache.org/r/38457/#comment156537>
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)
<https://reviews.apache.org/r/38457/#comment156538>
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.
Posted by Mesos ReviewBot <re...@mesos.apache.org>.
-----------------------------------------------------------
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.
Posted by Marco Massenzio <ma...@mesosphere.io>.
> 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.
Posted by Alex Clemmer <cl...@gmail.com>.
> 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.
Posted by Marco Massenzio <ma...@mesosphere.io>.
-----------------------------------------------------------
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.
Posted by Joris Van Remoortere <jo...@gmail.com>.
-----------------------------------------------------------
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.
Posted by Marco Massenzio <ma...@mesosphere.io>.
-----------------------------------------------------------
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.
Posted by Alex Clemmer <cl...@gmail.com>.
-----------------------------------------------------------
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.
Posted by Mesos ReviewBot <re...@mesos.apache.org>.
-----------------------------------------------------------
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.
Posted by Alex Clemmer <cl...@gmail.com>.
-----------------------------------------------------------
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.
Posted by Alex Clemmer <cl...@gmail.com>.
-----------------------------------------------------------
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.
Posted by Alex Clemmer <cl...@gmail.com>.
-----------------------------------------------------------
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