search

jrl-umi3218 / sch-core

Implementation and computation algorithms for the convex hulls
BSD 2-Clause "Simplified" License
13 stars 16 forks source link

missing cmake package config call added #19

Closed ahundt closed 5 years ago

ahundt commented 5 years ago

This fixes the problems described in: https://github.com/jrl-umi3218/jrl-cmakemodules/pull/124

coveralls commented 5 years ago

Coverage Status

Coverage remained the same at 55.465% when pulling 41621e1e7213707e04d217f6e510c8cd6be7333f on ahundt:grl into 73758820f086f7c1670439f134f4575940b170e6 on jrl-umi3218:master.

ahundt commented 5 years ago

See also: https://github.com/jrl-umi3218/jrl-cmakemodules/pull/124

ahundt commented 5 years ago

I've updated this pull request to use the other submodules as subtrees, which makes life easier, particularly when dealing with multiple forks of the repository.

ahundt commented 5 years ago

@gergondet

gergondet commented 5 years ago

I'd rather not switch to a sub-tree (this is also relevant to jrl-umi3218/Tasks#50)

In our experience (we used to have such a meta-repository + build script to get the full stack at once), the main benefit of working with sub-trees is in fact the initial clone/build which is simpler. However, it is also very easy to break the repository/history because it requires much more discipline (in particular when working across multiple repositories) to work with sub-trees.

ahundt commented 5 years ago

Some of the repositories are already sub-trees though and others aren't. I understand that problem, but modules don't work with forks by default, it will only go the original source, not the location actually inuse. Some of the bugs I need to be able to install on my system, particularly the python fixes, haven't been merged in the last couple years so I've needed to maintain things separately, and your submodules don't contain my commits which fix the build. Perhaps you have an alternative idea?

Maybe it used to be subtrees and the update instructions haven't been corrected? Isn't a mix of both subtrees and submodules worse? https://github.com/jrl-umi3218/Tasks#pulling-git-subtree

ahundt commented 5 years ago

I think this is a more minimal fix jrl-umi3218/sch-core#20 independent of subtrees/submodules.

gergondet commented 5 years ago

I understand that problem, but modules don't work with forks by default, it will only go the original source, not the location actually inuse.

This is surprising. I'd think you change the .gitmodules uri in the fork and run git submodule sync locally to make it work but I haven't tried that personally.

Some of the bugs I need to be able to install on my system, particularly the python fixes, haven't been merged in the last couple years so I've needed to maintain things separately, and your submodules don't contain my commits which fix the build. Perhaps you have an alternative idea?

Sorry about that. I think you are referring to jrl-umi3218/jrl-cmakemodules#124 I think we could merge that if that solves your issue.

Maybe it used to be subtrees and the update instructions haven't been corrected? Isn't a mix of both subtrees and submodules worse?

It's subtrees in Tasks because submodules don't work in subtrees and this was a problem for the (deprecated) meta-repository. This hasn't been changed since as ultimately it doesn't have much impact (we don't update the cmake subfolder in this repository these days). sch-core is (at least, was) used by more than one team and so the meta-repository handled it a bit differently as well in order not to break the workflow of other teams.

In summary, we still have some subtrees where we usually have submodules (typically cmake subfolder) for historical reasons and because there's very low activity related to these folders on these repositories. (imho, the main concern with subtrees is about "active" code)

gergondet commented 5 years ago

Closing following #22

FYI, all repositories in the "Tasks" stack will be using submodules with similar PR