[Texmacs-dev] Re: Compiling TexMacs on OSX

[Henri Lesourd]

Abdelrazak Younes wrote:

> Henri Lesourd 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?
Among other things:
http://www.ags.uni-sb.de/~omega/omega/index.php?target=plato


> >  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 policy is more costly, we cannot afford it, at least
not now.


> >  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.
For the purpose of contributions, you don't need binary componentization,
that's right.

But for the purpose of having people developing projects on top of
your software, you need it, because having to send patches and/or
to recompile the whole source code is not appropriate from the
point of view of an independent application.


> > >>> 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.

Read carefully: "on some platforms" means "there is no standard
solution". Thus perhaps you can do it, but it will remain a
hack depending on the particular compiler, kind of. Thus, it
is not very okay to use it.


> 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.
Hem, I have to admit you are right, here. That's a
useful thing to know :-).


> I hope I have clarified the matter.
You clarified the matter, no doubt (although the
magic receipt for the name mangling remains a little
bit mysterious, but probably there are ways to avoid
it).