[Texmacs-dev] Re: Compiling TexMacs on OSX

[Abdelrazak Younes]

Henri Lesourd wrote:
>  Abdelrazak Younes wrote:

>  By the way, I myself received a salary during four years precisely
>  because such a plugin project.


Glad for you. So is there some concrete example you can show us or is 
this confidential work?


> > So, if someone really is interested in adding a feature to TeXmacs,
> > I'll bet it's just easier to try to put in there directly.
> >
>  Definitely not: most of the time, the patch would be rejected, except
>  if the author is extremely careful in following the coding style.

Well, that's your project policy I guess. Instead of doing that, you 
could review the patches and educate the contributor to increase his 
coding style instead of just rejecting his patch. Of course, being more 
liberal will mean that the code quality will worsen here and there, but 
everything can be cleaned afterwards if needed.

>  This being said, there are parts of the codebase which are more
>  difficult than others.
>
>  In such a situation, the lack of extensions of TeXmacs becomes a
>  self-fulfilling prophecy, but as a matter of fact, it is mainly due
>  to the lack of componentization of the software.

I disagree. Componentization of the source code is a must have in order 
to let people contribute according to their field of expertise. But 
binary componentization is not required for that.

> >>> So, if this is the only reason for the glue library, I don't
> >>> see a very big added value.
> >>>
> >> The added value is that people can develop new widgets
> >> independently, and load these widgets inside TeXmacs *without the
> >> need of recompiling TeXmacs*.
> >
> >
> > You can do that with C++, I am 100% sure of this.
> >
>  Well, check your documentation. Mine says: [[ C++'s greatest
>  weaknesses in this area is the lack of a C++ ABI on some platforms
>  and the lack of a native notion of a dynamically linked library. ]]
>  B. Stroustrup (interview): C++: past, present, and future. Frontier
>  Channels, September 2006.

BS says "on some platforms". The ABI is stable with gcc (since 3.3 
IIRC), intel (I guess) and MSVC compilers. So, if you use gcc on Linux 
and Mac and MSVC on Windows, you are basically covering most user needs. 
WRT the "native notion of a dynamically linked library", that's true but 
that's very easy to work around with a few #ifdef and ten lines of code, 
out of my memory and minus one or two syntax error, this would give some 
thing like:

in MyPluginInterface.h:

/// My pure virtual class definition to be implemented by the plugin:
class MyPluginInterface {
...
};


in MyPlugin.cpp:

#ifdef _WIN32
typedef HINSTANCE dll_handle;
#define DLLEXPORT __declspec (dllexport)
#else
typedef void* dll_handle;
#define DLLEXPORT
#endif

/// function to implement in the plugin to retrieve the plugin instance:

DLLEXPORT MyPluginInterface * getPlugin();


in TeXmacs:

#ifdef _WIN32
dll_handle h = LoadLibrary("MyPlugin.dll");
MyPluginInterface ProcAdd=(DLL_GET_FUNCTION) GetProcAddress(h, 
"?Get@@YAPAVgetPlugin@@XZ");
#else
h = dlopen ("MyPlugin.so", RTLD_NOW);
GETRECEIVERFUNC mh_inst = (GETRECEIVERFUNC) dlsym(mh_inst, 
"_Z11getPluginP15");
#endif


et voilà, you have the full access to MyPluginInterface without having 
to export a thousand symbols.

>  Thus yes you can do it: but only if you wrap your C++ classes behind
>  a C API.

One C function to retrieve an object pointed is more than enough. 
Provided that MyPluginInterface.h stays stable, you won't have any problem.


> >>
> >> Thus the mechanism is 100% dynamic, and without a glue library
> >> which exports only a C API, it would not be possible to do things
> >> this way (otherwise, recompiling TeXmacs from source would be
> >> required each time you modify your plugins).
> >
> >
> > I still don't buy this argument, the C++ ABI has been stable for a
> > number of years already and many C++ applications support old
> > plugins without problem. Provided that you don't change the API the
> > plugins should continue to run just fine if TeXmacs is upgraded.
> >
>  Excuse me, but when I look at the dl_open() functions, I see
>  absolutely *nothing* which would allow me to fetch a class contained
>  inside a .so and call its constructor and methods.

See above. Constructor no, the dll should take care of the object 
instantiation.

>  Thus what you say seems interesting, but currently, it is a little
>  bit too much fuzzy to be useable information.

I hope I have clarified the matter.

Abdel.