> 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
> 
>

Reply via email to