Separate repo for Galois core from that for Lonestar apps

[yishanlu]

Right now Lonestar apps and Galois core share a common repo. It would be good to separate them into different repos so that external users only need to work with Galois core when writing their own apps. My use cases are OpenSTA (the timer in OpenROAD project led by UCSD) and Cyclone (asynchronous timer collaborated with Yale).

[amberhassaan]

I had discussed a slightly bigger vision with Keshav along the same lines: Separate Galois apps from library, but also split the library into a hierarchy of components/libraries. The motivation being:

1. not everybody needs everything.
2. The pieces we carve out can be useful stand-alone libraries and tools (I think there's an issue you opened asking to separate tools).

If you have some cycles for it, we can work together. I haven't had a chance to work on this yet, but I'm interested.

[yishanlu]

I agree with @amberhassaan. The issue you mentioned above is #54.

We just had our release meeting this morning, and decided that we will move the cmake configuration in Galois from "directory-based" to "target-based". Specifically, our plan follows:

1. Remove the app macro in the root CMakeLists.txt.
2. Let each application/target specify whatever targets it wants to link against; cmake should then take care of the transitive closure/hierarchy of related targets.

If the above changes are in place and #45 is resolved, Galois core can be used as libraries by both external users and Lonestar apps/tools. This means #54 will be automatically resolved.

For the Galois core, we will have multiple library targets so that users can choose only parts essential to them. For example, libgpu and libdist are not required for purely shared-memory applications. For some applications, e.g., python programs using Galois backend, .so is required; this should be addressable by the same mechanism we want here. Certainly a library can be built from other sub-libraries if there is no cyclic dependencies.

Separating repos for Galois core and Lonestar apps helps external users to reduce the code base they need to interact with should they decide to include Galois core as a git submodule. This is the case for OpenSTA.

[yishanlu]

By the way @insertinterestingnamehere and @ddn0 are leading the effort for Release 6.0 and they are working on this front. Feel free to get in touch with them if interested; my bandwidth now mainly goes to #89.

[amberhassaan]

I think target based linking is a good idea. I'd like to take it further to using dependencies (galois libraries) as submodule just like you mentioned (for OpenSTA?).

I'd like to split at least apps, dist-apps, libdist, libshared into their repos. The apps can use libdist/libshared as submodules. Similarly, tools can be a repo of its own. It may be difficult right now to split the repos right this moment if multiple people are pushing commits, so either everyone stops for a few days or we do this after the release.

I'm sorry I'm not contributing actively at the moments but thoughts from others are welcome, esp. @ddn0 & @insertinterestingnamehere

[ddn0]

I'd like to split at least apps, dist-apps, libdist, libshared into their repos. The apps can use libdist/libshared as submodules. Similarly, tools can be a repo of its own. It may be difficult right now to split the repos right this moment if multiple people are pushing commits, so either everyone stops for a few days or we do this after the release.

From my perspective, the must-have is to be able to use "core Galois" out of the source tree (for all the reasons everyone has mentioned above). For me, "core Galois" are the shared memory, GPU and distributed memory libraries. And this will be a matter of just following standard CMake tooling (importable targets, target-based linking, flags, etc.).

On having separate repos for core Galois, I'm not super keen because I think the overall goal of the Galois project is to have a unified substrate for compute and there might be linked changes to, for example, support multiple GPUs that require linked changes across libdist, libgalois, ... But I can be convinced otherwise.

For the apps themselves, I am more ambivalent about where they should go and there is merit for either case. Core Galois should transparently support either. For me, the biggest factor is how "hardened" the code is.

FWIW, the plan is to still keep a mono-repo along the following lines:

lib/galois
lib/dist
lib/...
lonestar/analytics/bfs/dist
lonestar/...

[amberhassaan]

@ddn0 , the plan you outlined is a good next step.

For me, separating the repos has some cosmetic advantages. Esp. for the new user, who let's say wants to "galoise" his/her app. The steps would be 1) add submodules for shared-galois and if the app is distributed, add dist-galois. 2) do Cmake hookups, which should be as simple as "add_subdirectory" but may be in reality we need to specify a few build flags as well. And that's it, I hope.

If we go this route and do these steps for lonestar apps (in their own separate repo), we can serve that as an example to follow for future users. Also, a minor advantage is that understanding the code structure becomes easier, but that may already be achieved by your new directory structure.

I do agree that there's a code dependency problem, where say a change in shared-galois breaks dist-galois. I don't have an answer for that and I'm still thinking about this pitfall. One the plus side, the git-submodule mechanism ensures that working build won't break until you update one or more submodules.

[roshandathathri]

We have decided to use the same repo for both library and apps. So should this issue be closed?

[ddn0]

Perhaps a more concrete question would be: @yishanlu is the current state of the repo sufficient to enable the sharing use cases you raised about OpenSTA and Cyclone?

[yishanlu]

For Cyclone I don't need the repos to be separated, since Cyclone is actually an app inside of Galois right now.

For OpenSTA, the current form works, though a repo with only Galois core libraries would be easier to handle with as a git submodule.