-
Notifications
You must be signed in to change notification settings - Fork 127
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
Remove DebugMode from all external APIs #3204
Conversation
Not yet sorted, for example, ADIOS2-Examples or done anything to enable building with old and new APIs. |
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 approve in concept. Obviously the implementation has to work, but yeah. 👍
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.
Thanks. This will make things much easier.
So, two further challenges assuming we go forward with this:
And then code that want to compile with all versions can test as follows (for whatever version we make the transition on )
|
Tied to: ornladios/ADIOS2-Examples#55 |
The actual appropriate conditional here, assuming that this becomes official with release 2.9.0 is: I think the only question is when we want to merge this. Because once we do, it might be hard, for example, to spin release 2.8.2 without having this in it. That would mean that we have an API change on a non-major release. But if we think we'll do 2.9.0 before minor releases (or are willing to spin 2.8.2 off 2.8.1 (rather than master) with only the update to fix whatever bug we're trying to fix), then I'd say lets get this merged... |
My attempt at keeping the debug mode api as an empty shim but explicitly marked as deprecated, at least for C and C++. Note the use of enable_if in the C++ bindings to prevent the |
So, I like things like the enable_if, but I assume that if this gets to the point where the ugly #ifdef's aren't necessary, then the contract tests will pass? |
6d1fb9f
to
c7554b8
Compare
@eisenhauer it took a few iterations to get it right, but the contract tests pass now and you can see the deprecation warnings when they build. |
I'm working out how to effectively do the same for the fortran interface |
Not many Fortran compilers support the deprecated attribute, at the moment all I can find is gfortran >= 11. That being said, it does work as expected:
produces:
|
So, let me summarize my understanding to see if I've got it right from the application point of view. For C++, we introduce the new (no debug-mode) API, but leave the old API in place, simply marking it deprecated so that they get warnings. That seems straightforward and a good way to go. Applications as they stand can compile with old and new ADIOS, when they delete the Debugmode parameter in their init calls, that doesn't change (though with old ADIOS they might not get the init call that they counted on, as per prior problems). Eventually we'll kill the deprecated APIs and all will be well for apps who have transitioned. I'm a little fuzzier on the C interface though. The init interfaces with a debugmode parameter (all of them?) have been marked deprecated. Do applications have a path for transitioning to an interface without a debugmode parameter? For creating code that would compile with both old and new versions of the API? I guess fortran is just an uglier version of the C question, with only gfortran supporting the deprecated warning. Anything to be done there? |
Correct
The
The C interface maps the existing
The Fortran situation is quite a bit better than C since Fortran 90 allows for function overloading based on arguments and essentially works the same way as the C++ interface in that applications can continue to use |
Ah, no idea Fortran had function overloading. Then again, 32 years is about how long it's been since I wrote much in the way of fortran... OK, so C++ is reasonable. C and some fortran users will get deprecated warnings until they change their code to call different routines, which they can start doing at any time and we should encourage that. I think that works for me. |
No description provided.