Skip to content
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

Fix Config File Machinery #45

Closed
insertinterestingnamehere opened this issue Nov 11, 2019 · 2 comments · Fixed by #112
Closed

Fix Config File Machinery #45

insertinterestingnamehere opened this issue Nov 11, 2019 · 2 comments · Fixed by #112
Assignees
Milestone

Comments

@insertinterestingnamehere
Copy link
Member

There's currently some old broken machinery for generating a config file with defines that are set at CMake configure time. That header is no longer included anywhere. It should be fixed and used to provide info about how Galois is configured. Specifically, it should be used to provide:

  • version information
  • the type of aborts used inside the lockable type in the Galois shared object.

Both of those things are currently set as compiler flags in our current CMakeLists, but we shouldn't expect downstream users of an installed library to be aware of the flags used to compile it. That information needs to be included in an installed config header so they can check things with #ifdef statements. This is especially important for our operator aborting code because the headers currently will assume exception based aborts by default even though the library builds with setjump/longjump based aborts by default.

@insertinterestingnamehere
Copy link
Member Author

The generated config header should also have compiler-specific macros that enable us to silence warnings in a targeted way. Currently we're doing this with compiler flags, but those options aren't automatically carried to end users.

@insertinterestingnamehere
Copy link
Member Author

With the warnings overhaul, we need to remember to check if the Intel diagnostics we set manually are even needed anymore now that we use the more stringent warning flags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants