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

[Henri Lesourd]

Josef Weidendorfer wrote:

> 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.
>
>  
You push back the problem in the direction of the
end users: what will they do when they will try to
load their plugin, and get an error "incompatible
binary, cannot load" ?

Ok, one can manage a way that it can work somehow,
but still, it's not perfect...


> Take Unix/GCC as an example. On other platform, there are other
> compilers able to force de-facto standards: MSVC on windows,
>  
The case of Windows is the most annoying,
because although MSVC is the de-facto,
we would also like to enable mingw...

In fact you are right, in most of the cases
the issue can be solved flawlessly (i.e.,
in such a way things work with no error).


> 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.
That was also my feeling.


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


> Its similar: The user uses the texmacs binary compiled with
> the compiler he/she has available on his system.
>  
Usually it is the case, but not always.


> 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).
>
>  
It seems sound.


> > 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).
>  
Difficult to believe this one, that's right. There *should*
be a problem somewhere, but it should be mostly compatible,


> But for sure, you can not load 32bit C DLLs into 64bit binaries on Windows.
>  
Okay for this one.


> > > 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)."
>
>
>  
That's probably the cleanest we can do, and it's
a useable solution, right.