Re: [Texmacs-dev] Re: Compiling TexMacs on OSX

[Josef Weidendorfer]

On Monday 23 June 2008, Henri Lesourd wrote:
> >Most compilers for a given platform adhere to a defacto standard
> >today.
> >
> "Most" of the compilers is not sufficient for
> a reliable solution, which should *always* work.

Then, make the runtime check more strict than really required,
e.g. force by the runtime check that the plugin has to be compiled
with the same compiler version. Then you never have a problem.

> >This is driven by the ubiquitousness of GCC, at least on
> >Unix.
> >
> UNIX is not the only game in town.

Take Unix/GCC as an example. On other platform, there are other
compilers able to force de-facto standards: MSVC on windows,
Apple-GCC on OS-X ...

> >But IMHO there is no problem to include a compiler check when loading
> >a plugin...
> >
> You need to be able to capture this information in
> the makefile. This is not infeasible, but still it's
> one more thing to do.

The check has to be done at runtime. But yes, you need a way to capture
the compiler name and version as a string which can be embedded in the code, 
both in
texmacs and in the plugin. No idea where to best put this in. Perhaps Makefile,
perhaps via predefined macros of different compilers in some header file.
You should be able to "steal" the method used by Qt for this.

> The problem is not to distribute binary versions: it
> is that the users should be able to donwnload and compile
> the source code of a plugin *only*, and then be able to
> load the object file inside a binary-installed TeXmacs
> such as an RPM-installed one for example.

Its similar: The user uses the texmacs binary compiled with
the compiler he/she has available on his system.
The texmacs binary package can come with the header files
needed to compile plugins (on Linux, these usually are distributed
via separate packages with extension "-devel"), or you could provide
the needed plugin headers to plugin developers via the texmacs web page
or the texmacs SVN repository (one should keep in mind that the
texmacs/plugin interface should be versioned to make it extensable).

> >But the compilers also have to agree on parameter passing convention, object
> >file layout (ELF/PE/COFF), 32 vs. 64bit architecture and so on. The latter 
> >dependencies
> >are also true for C functions.
> >  
> >
> As far as I know, e.g. under Windows, you can compile
> a DLL with *ANY* compiler, and it is always supposed
> to be loadeable an callable without any problems.

I don't know. Abdel gives a counter-example (which I honestly can not believe).
But for sure, you can not load 32bit C DLLs into 64bit binaries on Windows.
 
> >Would this be a serious obstacle your using C++ plugins with texmacs?
> >I seriously doubt this.
>
> Under Windows, it's annoying. But at least, if
> you can test the bad configurations, then it's
> quite okay.

Testing definitly is possible, and one can print out an error message such as:

 "There is an incompatibility with plugin XYZ, which was compiled with
 compiler ABC for the texmacs plugin interface version DEF. To be able
 to use it with this texmacs binary, it should be recompiled with compiler
 GHI using plugin headers from texmacs version JKL (check for updates to
 the plugin for this)."


Josef