You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, building downstream consumers of gFTL-shared such as pFUnit requires building all versions of all containers. It would be very nice if users could build only the set that they need. This would massively speed up builds.
I think this would be pretty easy to achieve. As well as adding each container to the gftl-shared library here:
I am not opposed. But this will unfortunately not help much for those that build gFTL-shared as a separate library. In that vein some CMake options to down select container categories and or template type parameters could help as well.
I'm presuming we won't hit some scaling issue with CMake by having so many targets?
Will you do the PR? (For your idea - not my follow on suggestion.)
That is true. I could imagine it would also add some pain during development if types change, or if the user can choose between single/double precision reals for instance. I'm not sure what a good interface would look like for that.
Currently, building downstream consumers of gFTL-shared such as pFUnit requires building all versions of all containers. It would be very nice if users could build only the set that they need. This would massively speed up builds.
I think this would be pretty easy to achieve. As well as adding each container to the
gftl-shared
library here:gFTL-shared/src/v2/CMakeLists.txt
Line 41 in 8b8a483
also make a new target just for that container:
Then users could link against
GTL_SHARED::String_Vector
for example, and only build what they require.The text was updated successfully, but these errors were encountered: