Abdelrazak Younes writes:
> Manoj Rajagopalan wrote:
>> There is no explanation for why libtool was removed last year. Does
>> anyone know?
>>
>
> Because it slows down compilation a lot.
And there was no evidence that we really needed it.
JMarc
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
Manoj Rajagopalan wrote:
There is no explanation for why libtool was removed last year. Does anyone
know?
Because it slows down compilation a lot.
Abdel.
There is no explanation for why libtool was removed last year. Does anyone
know?
-- Manoj
On Monday 04 January 2010 12:44:27 pm Pavel Sanda wrote:
> Manoj Rajagopalan wrote:
> > 6. Has someone tried all this before? What was the experience then?
>
> http://www.lyx.org/trac/changeset/27468
> pa
Manoj Rajagopalan wrote:
> 6. Has someone tried all this before? What was the experience then?
http://www.lyx.org/trac/changeset/27468
pavel
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
On Fri, Sep 08, 2006 at 01:47:46PM +0200, Peter Kümmel wrote:
> Andre Poenitz wrote:
> > IMO a common frontend base is a design mistake that puts things downside
> > up: The kernel tells the frontend to draw and listen to events from the
> > frontend. No good.
>
> I really wonder why this is accep
On Fri, Sep 08, 2006 at 04:22:25PM +0200, Peter Kümmel wrote:
> Jean-Marc Lasgouttes wrote:
>
> > You do not know much about LyX code obviously :) There are many ugly
>
> Isn't Friday today ???
You mean one of those six particular days of the week where multiple
bent exclamation marks following
On Thu, Sep 07, 2006 at 10:23:56PM +0200, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Andre> Because LyX architecture is ten years old and mvc wasn't
> Andre> exactly hyped at this time?
>
> Well, LyX is not older than smalltalk...
The Smalltalk h
On Fri, Sep 08, 2006 at 09:33:27AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Thu, Sep 07, 2006 at 09:39:13AM +0200, Abdelrazak Younes wrote:
> >>>Shouldn't there be a lyxkernel.dll and the frontend using this?
> >>The frontend virtual interface yes. The qt4 frontend will just be
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> Jean-Marc Lasgouttes wrote:
>> You do not know much about LyX code obviously :) There are many
>> ugly
Peter> Isn't Friday today ???
Indeed.
JMarc
Jean-Marc Lasgouttes wrote:
> You do not know much about LyX code obviously :) There are many ugly
Isn't Friday today ???
--
Peter Kümmel
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>> Peter Kümmel wrote:
>
Yes, we need a virtual frontend interface to support multiple toolkits,
but the virtual functions are not needed by the kernel, it doesn't know
the frontend (in a mvc design).
>>>
>>
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Yes, we need a virtual frontend interface to support multiple toolkits,
but the virtual functions are not needed by the kernel, it doesn't know
the frontend (in a mvc design).
In theory yes ;-)
Why do you think I got rid of W
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>> Andre Poenitz wrote:
On Thu, Sep 07, 2006 at 09:39:13AM +0200, Abdelrazak Younes wrote:
>> Shouldn't there be a lyxkernel.dll and the frontend using this?
> The frontend virtual interface yes. The qt4 front
Peter Kümmel wrote:
Andre Poenitz wrote:
IMO a common frontend base is a design mistake that puts things downside
up: The kernel tells the frontend to draw and listen to events from the
frontend. No good.
I really wonder why this is accepted as
fact and nobody complains about it, because
THIS
Jean-Marc Lasgouttes wrote:
>> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> Peter> I really wonder why this is accepted as fact and nobody
> Peter> complains about it, because THIS is the most ugly part of the
> Peter> lyx code.
>
> You do not know much about LyX code obviously :)
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Thu, Sep 07, 2006 at 09:39:13AM +0200, Abdelrazak Younes wrote:
Shouldn't there be a lyxkernel.dll and the frontend using this?
The frontend virtual interface yes. The qt4 frontend will just be an
implementation of this int
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> I really wonder why this is accepted as fact and nobody
Peter> complains about it, because THIS is the most ugly part of the
Peter> lyx code.
You do not know much about LyX code obviously :) There are many ugly
parts, we try to impr
Andre Poenitz wrote:
> IMO a common frontend base is a design mistake that puts things downside
> up: The kernel tells the frontend to draw and listen to events from the
> frontend. No good.
I really wonder why this is accepted as
fact and nobody complains about it, because
THIS is the most ugly p
Abdelrazak Younes wrote:
> Andre Poenitz wrote:
>> On Thu, Sep 07, 2006 at 09:39:13AM +0200, Abdelrazak Younes wrote:
Shouldn't there be a lyxkernel.dll and the frontend using this?
>>> The frontend virtual interface yes. The qt4 frontend will just be an
>>> implementation of this interface a
Andre Poenitz wrote:
> On Thu, Sep 07, 2006 at 09:39:13AM +0200, Abdelrazak Younes wrote:
>>> Shouldn't there be a lyxkernel.dll and the frontend using this?
>> The frontend virtual interface yes. The qt4 frontend will just be an
>> implementation of this interface and could entirely be in a sing
Andre Poenitz wrote:
On Thu, Sep 07, 2006 at 09:39:13AM +0200, Abdelrazak Younes wrote:
Shouldn't there be a lyxkernel.dll and the frontend using this?
The frontend virtual interface yes. The qt4 frontend will just be an
implementation of this interface and could entirely be in a single dll.
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Because LyX architecture is ten years old and mvc wasn't
Andre> exactly hyped at this time?
Well, LyX is not older than smalltalk...
JMarc
On Thu, Sep 07, 2006 at 09:30:18AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote:
> >>I have started with frontend/qt4/ but give up because qt4 needs several
> >>functions from the other libs.
> >>We must start at the bottom n
On Thu, Sep 07, 2006 at 09:41:55AM +0200, Abdelrazak Younes wrote:
> >Mathed depends on the core _and_ on the painert stuff, so how could that
> >be a good candidate to start with?
>
> This was just a guess as the mathed code seems pretty isolated from the
> rest of the LyX code. As you said in a
On Wed, Sep 06, 2006 at 08:49:35PM +0200, Peter Kümmel wrote:
> > The problem with the current architecture is, of, course, that drawing
> > is 'pushed' by the kernel, not 'pulled' by the frontend (containing th
> > painter)
>
> Yes, building insets is completely hopeless. And this artifact wa
On Thu, Sep 07, 2006 at 09:39:13AM +0200, Abdelrazak Younes wrote:
> >Shouldn't there be a lyxkernel.dll and the frontend using this?
>
> The frontend virtual interface yes. The qt4 frontend will just be an
> implementation of this interface and could entirely be in a single dll.
> This way the
Andre Poenitz wrote:
On Tue, Sep 05, 2006 at 10:59:41AM +0200, Abdelrazak Younes wrote:
Peter Kümmel wrote:
At the current stage the code is full of dependencies,
and some circular could only be solved by moving functions
into a other library.
I think you should forget about the controller for
Andre Poenitz wrote:
On Tue, Sep 05, 2006 at 10:37:27AM +0200, Abdelrazak Younes wrote:
That's exactly the problem indeed. My earlier cleanup work is heading
toward "the frontend use the kernel as a library" design. Once this is
achieved, splitting out the toolkit specific frontend should be ea
Andre Poenitz wrote:
On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote:
I have started with frontend/qt4/ but give up because qt4 needs several
functions from the other libs.
We must start at the bottom not at the top, and qt4 is at the top.
Exactly.
The problem with the current ar
Peter Kümmel wrote:
Andre Poenitz wrote:
On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote:
I have started with frontend/qt4/ but give up because qt4 needs several
functions from the other libs.
We must start at the bottom not at the top, and qt4 is at the top.
Exactly.
The problem
Andre Poenitz wrote:
> On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote:
>> I have started with frontend/qt4/ but give up because qt4 needs several
>> functions from the other libs.
>> We must start at the bottom not at the top, and qt4 is at the top.
>
> Exactly.
>
> The problem with
On Tue, Sep 05, 2006 at 11:16:14AM +0200, Peter Kümmel wrote:
> I have started with frontend/qt4/ but give up because qt4 needs several
> functions from the other libs.
> We must start at the bottom not at the top, and qt4 is at the top.
Exactly.
The problem with the current architecture is, of,
On Mon, Sep 04, 2006 at 09:28:33PM +0200, Peter Kümmel wrote:
> I've started to build shared libraries instead of static ones,
> because linking is so slow under windows.
>
> I only have successfully build the support library after
> some small file moving (from src to supp
On Tue, Sep 05, 2006 at 10:59:41AM +0200, Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>
> >At the current stage the code is full of dependencies,
> >and some circular could only be solved by moving functions
> >into a other library.
>
> I think you should forget about the controller for now an
On Tue, Sep 05, 2006 at 10:37:27AM +0200, Abdelrazak Younes wrote:
> That's exactly the problem indeed. My earlier cleanup work is heading
> toward "the frontend use the kernel as a library" design. Once this is
> achieved, splitting out the toolkit specific frontend should be easy. So
> clearly
ccessfully build the controllers as shared lib under linux.
It seems that on linux shared libraries are not so encapsulates
as on windows.
--
Peter Kümmel
Lars Gullik Bjønnes wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> | Abdelrazak Younes wrote:
> | > Georg Baum wrote:
> | >> Am Montag, 4. September 2006 22:48 schrieb Peter Kümmel:
> | >>> Georg Baum wrote:
> | Why are circular dependencies a problem? It is a long time ago, but
> | >
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > Georg Baum wrote:
| >> Am Montag, 4. September 2006 22:48 schrieb Peter Kümmel:
| >>> Georg Baum wrote:
| Why are circular dependencies a problem? It is a long time ago, but
| >> IIRC I
| created dlls with circular
Peter Kümmel wrote:
Abdelrazak Younes wrote:
That's exactly the problem indeed. My earlier cleanup work is heading
toward "the frontend use the kernel as a library" design. Once this is
achieved, splitting out the toolkit specific frontend should be easy. So
clearly the first candidate for a new
ated
> on the frontend. Mathed seems also to be a good candidate.
>
> [...]
>> Is there a chance that something like this could be checked in?
>> If not I could spare my time.
>
> I would welcome this change but last time I brought this issue I was
> back fired.
>
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> Am Montag, 4. September 2006 22:48 schrieb Peter Kümmel:
>>> Georg Baum wrote:
Why are circular dependencies a problem? It is a long time ago, but
>> IIRC I
created dlls with circular dependencies during my diplom thesis.
Geo
.
[...]
Is there a chance that something like this could be checked in?
If not I could spare my time.
I would welcome this change but last time I brought this issue I was
back fired.
But supporting shared libraries is like another code cleanup,
which makes the libraries more independent from
Georg Baum wrote:
Am Montag, 4. September 2006 22:48 schrieb Peter Kümmel:
Georg Baum wrote:
Why are circular dependencies a problem? It is a long time ago, but
IIRC I
created dlls with circular dependencies during my diplom thesis.
Georg
Yes, but this needs a two pass build process, whi
Am Montag, 4. September 2006 22:48 schrieb Peter Kümmel:
> Georg Baum wrote:
> > Why are circular dependencies a problem? It is a long time ago, but
IIRC I
> > created dlls with circular dependencies during my diplom thesis.
> >
> >
> > Georg
> >
> >
>
> Yes, but this needs a two pass build
Georg Baum wrote:
> Am Montag, 4. September 2006 22:21 schrieb Peter Kümmel:
>
>> At the current stage the code is full of dependencies,
>> and some circular could only be solved by moving functions
>> into a other library.
>
> Why are circular dependencies a problem? It is a long time ago, but I
Am Montag, 4. September 2006 22:21 schrieb Peter Kümmel:
> At the current stage the code is full of dependencies,
> and some circular could only be solved by moving functions
> into a other library.
Why are circular dependencies a problem? It is a long time ago, but IIRC I
created dlls with circ
Lars Gullik Bjønnes wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> | I've started to build shared libraries instead of static ones,
> | because linking is so slow under windows.
> |
> | I only have successfully build the support library after
> | som
Peter Kümmel <[EMAIL PROTECTED]> writes:
| I've started to build shared libraries instead of static ones,
| because linking is so slow under windows.
|
| I only have successfully build the support library after
| some small file moving (from src to support).
|
| Then I've trie
I've started to build shared libraries instead of static ones,
because linking is so slow under windows.
I only have successfully build the support library after
some small file moving (from src to support).
Then I've tried to do the same with controllers, but there are
so much depen
Jean-Marc Lasgouttes wrote:
> > "Peter" == Peter Firmstone <[EMAIL PROTECTED]> writes:
>
> Peter> I seem to be having some difficulty compiling lyx with shared
> Peter> libraries only, as I want to create a package for debian for
> Peter> sparc processors. Is this normally possible?
>
> I g
> "Peter" == Peter Firmstone <[EMAIL PROTECTED]> writes:
Peter> I seem to be having some difficulty compiling lyx with shared
Peter> libraries only, as I want to create a package for debian for
Peter> sparc processors. Is this normally possible?
I guess it should.
Peter> I seem to be missin
I seem to be having some difficulty compiling lyx with shared libraries
only, as I want to create a package for debian for sparc processors. Is
this normally possible?
The attachment lyxbug2 (excuse the name, just my naming convention)
contains the output from the compiler when it started to
54 matches
Mail list logo
