[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Texmacs-dev] Re: Compiling TexMacs on OSX
From: |
Henri Lesourd |
Subject: |
[Texmacs-dev] Re: Compiling TexMacs on OSX |
Date: |
Mon, 23 Jun 2008 12:35:59 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 |
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).
- [Texmacs-dev] Re: Compiling TexMacs on OSX, (continued)
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/20
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/20
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/20
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/20
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/20
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/20
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/21
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/21
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Henri Lesourd, 2008/06/23
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/23
- [Texmacs-dev] Re: Compiling TexMacs on OSX,
Henri Lesourd <=
- [Texmacs-dev] Re: Compiling TexMacs on OSX, Abdelrazak Younes, 2008/06/23
- [Texmacs-dev] C++'s frustrations, Henri Lesourd, 2008/06/23
- [Texmacs-dev] Re: C++'s frustrations, Abdelrazak Younes, 2008/06/23
- [Texmacs-dev] Re: C++'s frustrations, Henri Lesourd, 2008/06/23
- [Texmacs-dev] Re: C++'s frustrations, Abdelrazak Younes, 2008/06/23
- [Texmacs-dev] Re: C++'s frustrations, Henri Lesourd, 2008/06/23
- Re: [Texmacs-dev] Re: C++'s frustrations, Vadim Konovalov, 2008/06/23
- Re: [Texmacs-dev] Re: C++'s frustrations, Henri Lesourd, 2008/06/23
- [Texmacs-dev] Re: C++'s frustrations, Abdelrazak Younes, 2008/06/23
- Re: [Texmacs-dev] Re: Compiling TexMacs on OSX, Josef Weidendorfer, 2008/06/23