Manoj Rajagopalan wrote:
Hi developers,
I just successfully completed an experiment with using libtool to build all
LyX component libraries as shared libraries and building the lyx executable
to link with these instead of the static libs. Is this something that might
be worth submitting? With libtool, by default, both static and shared libs
get built and one may continue to work with static builds with
the '--enable-static=yes --enable-shared=no' flags passed to configure.
I am interested in creating a mini mathematical editor that I can embed in
my applications and I was interested in using lyx code to supply this
functionality. The natural first step was to build LyX using shared libraries
so that I could prototype my code.
A few issues:
0. Is this change desirable? With this LyX might begin to supply components to
other open source applications. For example, I have long wished that I could
annotate my research paper database in kBibTeX with WYSIWY[GM] mathematical
notes.
1. Libraries like lyxcore and lyxinsets seem to be referencing functions
defined in .o files for the main lyx application instead of in other
libraries. Because of static linkage this is hardly a problem but is it
possible to tidy up the architecture a bit so that this issue is fixed?
I suspect this won't be easy or even desirable. What is possible on the
other hand is to make a dll of the support code (in src/support/) and
another on for everything in src/ except for support/ and frontend/qt4/.
But instead of going that that I would suggest first that you try to
encapsulate the whole of the source code inside a dll first. >What's
required is to get rid of the main function and to rework a bit
GuiApplication.
2. Because of the above, I had to move all .cpp except main.cpp for the lyx
program into another library (which I unimaginatively named liblyxcore2) and
it was only after this that lyxclient could be successfully linked.
3. autogen.sh will need to contain a call to libtoolize so that ltmain.sh is
written into the config/ directory without which the libtool initialization
macros in configure.ac will fail. This should still work on older autotools
versions which automatically call libtoolize (newer versions don't)
4. Very small changes are required in configure.ac and in all the Makefile.am
to achieve shared libraries. However, build tests must be performed on all
supported platforms before this change is accepted. If this change is
desirable, how can the development community go about testing and accepting
it? Are there folks who have volunteered to test the build on platforms like
Windows and MacOS?
Mac developers use either autotools or cmake, Windows devs use scons or
cmake. Cygwin devs (Enrico) uses autotools.
I suggest you try to experiment with CMake first as this is easier and
changes in there this could be easily accepted.
Abdel.
