Considering removal of .def files

[isaevil]

Considering Removal of .def Files

Since PR #1114 was merged, we now have two simultaneously active approaches for exporting symbols:

• Using GCC visibility attributes.
• Using Module-Definition (.def) files on Windows or linker version scripts on Unix-like systems.

Having duplicate approaches raises the question of whether we should keep both or remove .def files.

Advantages of .def Files

• Better control: .def files provide detailed control over the exported symbols, allowing you to specify exactly which functions and variables should be exported, thus reducing the likelihood of unexpected exports in the future.

• Separation of concerns: Using .def files keeps the export logic separate from the source code, unlike visibility attributes which are scattered across the entire codebase.

NOTE: .def files alone won't work as expected when global visibility flags are set (i.e. -fvisibility=hidden set). See Issue #779.

Advantages of GCC Visibility Attributes

• Easier to use: Unlike .def files, you don't need to manually list all the mangled C++ symbols you want to export. Instead, you add visibility attributes to individual functions, classes, methods, or variables you want to export.

• Room for optimizations: From the GCC wiki: "Furthermore, using linker version scripts doesn't permit GCC to better optimize the code."

Concerns Regarding Removal of .def Files

• All exports are scattered across the codebase, making it harder to maintain.
• .def files have proven to be a reliable approach to export symbols. Are we sure that we won't face any unexpected issues while using visibility attributes?

One possible mitigation is to have a reference file containing a list of symbols expected to be exported. Then, introduce an additional check in the CI to verify integrity against this file:

1. Each system configuration will have a separate reference list of symbols to export (much like .def).
2. Separate GH Actions job will compare exported symbols from the binaries with the reference list.

Essentially, we'll end up in the similar situation except these symbols lists will be now a part of the infrastructure, not the product.

Seems like we can then just keep them both, there is no issue with them being active at the same time.
However, we need to keep them in sync. If a symbol is missed in the .def file or TBB_EXPORT isn't added to it, it won't be exported.

[phprus]

We can make two builds (with -fvisibility=hidden and with def-based export) and compare exported symbols.

I suggest adding a def-based build to each CI task and comparing symbols. We can make def-based build without tests to reduce build time.
Or make separated CI task with two builds, compare exported symbols and swap lib files and run ci tests.