git submodules -1 Having the fabtests in the same git repository would be nice. If there are changes to libfabric that would need corresponding updates to fabtests to get it to work you could put all that into one git commit.
One ask: don’t integrate fabtests into the libfabric build. I would prefer to have fabtest in its own directory with its own autogen.sh/configure/libtool build system, packaging, etc. From: ofiwg [mailto:[email protected]] On Behalf Of Wesley Bland Sent: Monday, August 27, 2018 8:25 AM To: Jeff Squyres <[email protected]> Cc: OFIWG Mailing list <[email protected]> Subject: Re: [ofiwg] sharing code between libfabric and fabtests I agree. We have both submodules and the tests in the MPICH repository (for separate things obviously) and I can say that while our use of submodules makes sense (we don’t want to include all of libfabric in the MPICH tree), it’s a pain. Having the tests in the same repo makes sense. I can think of other projects that keep the test bucket separate, but I think it’s usually for license reasons rather than cleanliness. Thanks, Wesley On Aug 25, 2018, at 7:28 AM, Jeff Squyres (jsquyres) <[email protected]<mailto:[email protected]>> wrote: My $0.02: don't use git submodule. It's more complicated than you think. Merging the repos would be fine with me. On Aug 25, 2018, at 1:47 AM, Jeff Hammond <[email protected]<mailto:[email protected]>> wrote: TL;DR merge the repos. I honestly don’t know why any project would separate the test bucket from the implementation except strictly at the git repo level i.e. test bucket repo is assumed to be git submodule in implementation repo. Jeff On Fri, Aug 24, 2018 at 5:23 PM Hefty, Sean <[email protected]<mailto:[email protected]>> wrote: Because of the need to support OS and platform portability, there's a small, but growing, amount of code that needs to be shared between fabtests and libfabric. Today the code has been duplicated. (As an example, the definitions for complex data types are duplicated). I know git has a submodule option (and subtree) that's close to what we need. We might also be able to use some sort of build script to pull in the related files. We could even move the shared code into a separate repo used by both, which might make submodules friendlier, and is probably the 'right' choice... Does anyone have ideas as to the best option here? - Sean _______________________________________________ ofiwg mailing list [email protected]<mailto:[email protected]> https://lists.openfabrics.org/mailman/listinfo/ofiwg -- Jeff Hammond [email protected]<mailto:[email protected]> http://jeffhammond.github.io/ _______________________________________________ ofiwg mailing list [email protected]<mailto:[email protected]> https://lists.openfabrics.org/mailman/listinfo/ofiwg -- Jeff Squyres [email protected]<mailto:[email protected]> _______________________________________________ ofiwg mailing list [email protected]<mailto:[email protected]> https://lists.openfabrics.org/mailman/listinfo/ofiwg
_______________________________________________ ofiwg mailing list [email protected] https://lists.openfabrics.org/mailman/listinfo/ofiwg
