I figure the bundled code's function names have to all be changed, ...

If I read this correctly, we'd have to change the source code of the bundled libs, something I'd really want to avoid. Adding a namespace would help, but that needs C++ whereas the libs are all pure C code. I tried to compile the libs with a C++ compiler but that failed for several reasons.

I imagine an approach like this:

$ git diff
diff --git a/FL/Fl_Adjuster.H b/FL/Fl_Adjuster.H
index c2e308128..3af85d80e 100644
--- a/FL/Fl_Adjuster.H
+++ b/FL/Fl_Adjuster.H
@@ -26,6 +26,8 @@
 #include "Fl_Valuator.H"
 #endif
 
+namespace FL_ADJ {
+
 /**
   The Fl_Adjuster widget …
@@ -64,4 +66,8 @@ public:
   int soft() const {return soft_;}
 };
 
+} // namespace FL_ADJ
+
+using namespace FL_ADJ;
+
 #endif

1. As you can see (almost) the entire header Fl_Adjuster.H (I arbitrarily picked one) is surrounded by namespace FL_ADJ {...} which could in practice be in a separate file that includes the original source file. This way the original source would not need to be changed.
2. The trailing using namespace FL_ADJ; would normally be expected in the user (consumer) source code but is in the header file for simplicity.
3. With this simple proof of concept we have changed the entire class Fl_Adjuster to class FL_ADJ::Fl_Adjuster, i.e. we put it into a namespace.
4. With this simple change the entire FLTK lib and test files can be built.
5. That's how I would like to deal with the bundled libs.
6. User code would then only have to include the appropriate header file and get the correct linkage.

That's only a proof of concept, details need to be worked out. The problem with the bundled libs is that we really need to change the "names" which could ideally be done with such a namespace trick without editing the source code, but unfortunately I couldn't find a similar way to do it for zlib. Still thinking about a good way, but for today I had to give up.

FYI: The reason why I absolutely don't want to "edit" the source code of the bundled libs is that it would make the maintenance (upgrading) really hard. And I'm the one who did this in the past, I know what I'm talking about. It's pretty straightforward now (with a little diff magic) but I'm afraid it would be much harder if we had to edit the source code.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.