> Do you see a way that we could do this without having to change all
> the existing uses of these macros inside Octave?
>
> I'm don't think I understand the rules for when to include OCTAVE_API
> or not, so using these macros will likely lead to mistakes that won't
> be caught by people who use systems that don't need the APIdefinitions.
>
> Can you explain more completely what the problem was with compiling
> the Octave Forge code?
When porting octave to MSVC, I had to export a lot of stuffs to make
them visible in the DLL's (liboctave/ and src/); hence I introduce OCTAVE_API,
which expands to dllexport of dllimport, depending on the context. To ease the
work in liboctave, where a lot of code is macro-based, I hard-coded this
modifier (OCTAVE_API) in some base macros, such that it would be used
automatically at higher levels (and it didn't change the macro signature)
This appears to be a bad idea, because those macros are hard (even impossible)
to use outside liboctave/ source tree. The problem really popped up in the fixed
package of octave-forge, which uses lots of these macros to define the various
fixed types and operators; hence it also expands OCTAVE_API, which is
hard-coded. However, the code in the fixed package also includes headers from
liboctave/, which also use the same macros with the same OCTAVE_API.
And here's the problem:
1) in the fixed package code, you want OCTAVE_API to be expanded into
dllexport or the empty string, but not dllimport (actually, I want dllexport. because
I compile the fixed support into a DLL)
2) in the headers included by the fixed package code, you want OCTAVE_API
to be expanded into dllimport (otherwise you'll get a link error).
And you want these 2 opposite behavior when compiling the same source
file. I realized the problem was this hard-coded OCTAVE_API and my
patch proposal tries to solve the problem by making this function modifier
a parameter of the macros. This is the most elegant and flexible solution I
could think of, but it's also the most intrusive one. Maybe there are other
possibilities, but I couldn't find another one. (I tried by undefining explicitely
OCTAVE_API and redefining it, but this didn't lead me very far and this
didn't change the fact that the macros is hard to use outside liboctave/).