Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds a Data Transport Layer to DYAD to support different ways of transferring data #24
Adds a Data Transport Layer to DYAD to support different ways of transferring data #24
Changes from all commits
f5b8ffe
1f06a9f
e8d7689
027a9e1
4850a34
1be0887
defc786
846aa6d
f346084
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding -I for finding header files within such cases would make it harder to install the correct files later. The convension is to use till src only in -I so that other libraries can correctly link to DYAD at runtime.
Another general project level comment is that it is good to make distinction between public header files and private header files within a project.
This will help the installer only install the header files expected to be used by applications and rest would not be installed in include but would be compiled together in the so itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I absolutely agree with you @hariharan-devarajan, but I did this because we wanted to stay (relatively) consistent with Flux. This
flux-core
repo does something similar to this in itsMakefile.am
s.However, regardless of what Flux does and how much we want to follow that, I also believe that any changes we might want to make regarding organization of files should belong in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that we should put more effort to clean up installation and make distinction between public headers and private headers. This can be worked on in a followup PR.