Re: Reorganize 3rdparty directory

Hi All, Sorry for the delay in getting back to this issue. I have now created RRs starting at https://reviews.apache.org/r/46514/ that flatten 3rdparty/. We have also added a new configure flag --enable-install-module-dependencies, to allow installation of module dependencies. Over the next few

Re: Reorganize 3rdparty directory

Good question. At this point, libmesos should build, but the CMake build has fallen a bit behind, since I've been mostly concentrating on the integration work. That said, I do expect a bunch of patches to go in tomorrow that will re-un-break the libmesos CMake build, and following that, the

Re: Reorganize 3rdparty directory

> > Overall, the changes are extremely small. We (apparently) did a pretty > good job of making the CMake configuration scripts modular and > consumable by arbitrary projects ah, the warm, fuzzy feeling that one experiences when all the hard work of abstracting stuff pays off :-) well done,

Re: Reorganize 3rdparty directory

Folks: Took about 30 minutes to put together a prototype of the great `3rdparty` flattening. Please see the (extremely preliminary) review[1] or my working branch[2] for a really close approximation of the number of changes to the CMake build system we'd need to support this flattening. Overall,

Re: Reorganize 3rdparty directory

I am also a fan of git submodules in the long term, but avoiding them in the short term. We should get things organized as we want them first, and then start thinking about pulling libprocess/stout out into submodules later (while also preserving their history!) I disagree with moving libprocess

Re: Reorganize 3rdparty directory

Thanks for bringing it up Alexander! I don't have a strong opinion wrt git submodules since I don't have much experience with them personally. Having said that, I would like to go conservative on this one (baby steps :-) ). Further, I do understand that moving libprocess and stout directories

Re: Reorganize 3rdparty directory

If we go to git submodules, please ensure there are good docs around how to update cloned repos. e.g., From ansible: https://docs.ansible.com/ansible/intro_installation.html Note when updating ansible, be sure to not only update the source tree, but also the “submodules” in git which point at

Re: Reorganize 3rdparty directory

+1 I am one who is totally in for that change. It is not only the directories problem, but the structure which has led that the stout tests (which do need to be compiled) are actually managed in the libprocess Makefile, on top of all the things you have already mentioned. > On 09 Feb 2016, at

Re: Reorganize 3rdparty directory

This is a great initiative and something I wanted to do since the first day I did `git clone` for Mesos :) Happy to help wherever I can, Kapil - just say the word! In my opinion, we should take full advantage of git submodules and move stout/libprocess out into their own repositories (which,

Reorganize 3rdparty directory

Hi All, TLDR: Move everything from 3rdparty/libprocess/3rdparty/* into 3rdparty/. (Optionally) Move libprocess/stout to the top-level directory. I wanted to start some discussion around reorganizing stuff inside "3rdparty". I apologize for the length of the email, please bear with me.

Re: Reorganize 3rdparty directory

> > However, in the current code base, we don't strictly follow the 3rdparty > structure. For example, stout has a dependency on picojson and > google-protobuf, but we don't put these two packages inside > 3rdparty/libprocess/3rdparty/stout/3rdparty/. My understanding is that stout is header

Re: Reorganize 3rdparty directory

On Tue, Feb 9, 2016 at 7:20 PM, Jie Yu wrote: > > > > > However, in the current code base, we don't strictly follow the 3rdparty > > structure. For example, stout has a dependency on picojson and > > google-protobuf, but we don't put these two packages inside > >

Re: Reorganize 3rdparty directory

Kapil, I guess what I want to understand is why the existing structure makes it hard for you to do the things that you want to do (installing module-specific 3rdparty dependencies into "${pkglibdir}/3rdparty" as part of "make install"). The only reason you mentioned in the original email is that

Re: Reorganize 3rdparty directory

On Tue, Feb 9, 2016 at 8:23 PM, Jie Yu wrote: > Kapil, > > I guess what I want to understand is why the existing structure makes it > hard for you to do the things that you want to do (installing > module-specific 3rdparty dependencies into "${pkglibdir}/3rdparty" as part >