Closed alt-graph closed 1 year ago
Maybe we should not have changed upstream at all. Just dump all the original files here and we put something around it.
Hmm, the workflow has not been triggered? It should show the tests on every PR :thinking: Will try to find out the reason later.
Maybe we should not have changed upstream at all. Just dump all the original files here and we put something around it.
Yes, maybe. But that would have added two more include files and a non-GUL14 top-level namespace. Once I "standardized" that to gul14, we had clashing symbol names. Sigh.
Alternatively we could have taken the entire unit test suite.
That is why I want to have C++17 proper (and a matching GUL version) ;-) We are in 2023 now. C++20 should be our bleeding edge and not 17 :grimacing:
Maybe adding "their" test suite completely is a good approach, if that is not too much work. I imagine that can be also quite time consuming, adapting all the namespaces...
That is why I want to have C++17 proper (and a matching GUL version) ;-) We are in 2023 now. C++20 should be our bleeding edge and not 17 😬
We should discuss if we really want to invest the time to make a GUL17. My hope is that we could jump directly to GUL20 next year, but if that is not realistic, we should move to 17 ASAP.
Maybe adding "their" test suite completely is a good approach, if that is not too much work. I imagine that can be also quite time consuming, adapting all the namespaces...
... and it would be sheer luck if anyone used Catch2 for their test suite. Rewriting that for a different framework would be painful.
really want to invest the time to make a GUL17
I see that only as dropping stuff that is in the Standard. For GUL20 we would also need to drop the same stuff. So no work is lost I guess, and GUL20 becomes easier. Maybe I should just create it (it = GUL17) as workflow :-D With some luck it will survive additions to GUL14 and automatically adapt. How hard can that be :grimacing:
I see that only as dropping stuff that is in the Standard. For GUL20 we would also need to drop the same stuff. So no work is lost I guess, and GUL20 becomes easier. Maybe I should just create it (it = GUL17) as workflow :-D With some luck it will survive additions to GUL14 and automatically adapt. How hard can that be 😬
You forget the migration of the DOOCS libraries and servers. There is quite a chunk of work there, and it makes a difference if we do that once or twice in the next two years.
It seems I underestimated the import of the
variant
header. In fact,gul14::visit()
could not be used at all (at least for some set of compilers) because of a missing namespace qualifier on one call toinvoke()
. Here's a bugfix.