search

flux-framework / dyad

DYAD: DYnamic and Asynchronous Data Streamliner
GNU Lesser General Public License v3.0
7 stars 5 forks source link

Replaces the use of Makefiles with the Autotools #2

Closed ilumsden closed 2 years ago

ilumsden commented 2 years ago

This PR replaces the vanilla Makefiles with the use of the Autotools. As a result of this PR, DYAD now depends on the following:

Because a version number is required for the Autotools, this PR currently gives DYAD a placeholder version of 0.1.0. The "real" initial version (including development status, like alpha, beta, etc.) should probably be decided before merging this PR.

This PR also copies two files from flux-core into DYAD:

Finally, this PR adds a new dyadrun script. This script allows users to set DYAD's environment variables using command-line arguments (instead of having to remember all those env vars). Additionally, it will also run the specified program (by interpreting the first unrecognized, non-flag argument as the program name). So, for example, if you have the application consumer that uses the wrapper API, DYAD is managing the path /tmp/app, and DYAD's KVS namespace is test, you could run the following:

$ dyadrun -c -pre -path /tmp/app -n test consumer

If searching for this script in the repository, it is actually under the name dyadrun.in. When building DYAD, Automake will replace some template variables defined in dyadrun.in to create dyadrun. During install, the build system will install dyadrun into the bindir.

@JaeseungYeom one thing that will need to be done in the future for dyadrun is that the usage statement will need to be updated so that the flags corresponding to DYAD_SHARED_STORAGE, DYAD_NUM_CPA_POINTS, and DYAD_SYNC_CHECK are documented. Additionally, if any of the other flags' documentation is incorrect, please let me know, and I'll fix it.

JaeseungYeom commented 2 years ago

I think you can rebase the commits to a smaller number of commits. I see you are using flux-core autogen.sh as the reference. I wonder if it makes sense to look into flux-sched instead because flux-sched requires flux-core installation, which is similar to dyad. Don't worry about DYAD_NUM_CPA_POINTS. Anything CPA related will be removed from the codebase.

ilumsden commented 2 years ago

I can definitely rebase. Just wanted to get everything onto GitHub first. As for the autogen.sh stuff, I can definitely take a look at flux-sched, although I don't think it'll make much of a difference. autogen.sh is literally 2 lines of code (plus some echos).

ilumsden commented 2 years ago

@JaeseungYeom the only difference between the version of autogen.sh in flux-core and the version in flux-sched is that the flux-core version uses the --force flag with autoreconf. Otherwise, they're identical.

ilumsden commented 2 years ago

@JaeseungYeom for the initial version info in configure.ac, we should be using SemVer 2.0.0 if we're sticking with the Flux project's release structure (https://flux-framework.readthedocs.io/projects/flux-rfc/en/latest/spec_1.html#release-process).

Per SemVer 2.0.0, we should probably be using 0.Y.Z version numbers right now. These version numbers are meant for public APIs that aren't 100% stable. Although I don't think the APIs are going to change much, if at all, for C and C++, I personally think it would make sense to avoid locking the APIs in for the time being.

So, to that end, the "placeholder" version that I have in configure.ac (i.e., 0.1.0) would be perfectly fine to use for the time being. We could add a tag to the version (e.g., alpha or dev), but I don't know if that's necessary.

JaeseungYeom commented 2 years ago

if you need to change anything for PerfFlowAspect, make that change, rebase and merge.

JaeseungYeom commented 2 years ago

please squash the commits into one.

JaeseungYeom commented 2 years ago

All the commits except the PFA support should be in one commit. So, there should be two commits.