Georg Baum wrote:
Abdelrazak Younes wrote:
OK, I will solve that by creating a static instance in docstring.C and
get rid of the code in lyx_main.C.
Does that work? IIRC you did not want to do that last time because it could
break (undefined initialization order of static objects).
Year tha
Abdelrazak Younes wrote:
> OK, I will solve that by creating a static instance in docstring.C and
> get rid of the code in lyx_main.C.
Does that work? IIRC you did not want to do that last time because it could
break (undefined initialization order of static objects).
Georg
Georg Baum wrote:
Abdelrazak Younes wrote:
As long as support is a static library, I don't think there is a
dependency problem here.
There is one (nothing in src/support should depend on anything in src), but
we had exactly the same discussion already, so I am not going to repeat the
argument
Georg Baum wrote:
Abdelrazak Younes wrote:
As long as support is a static library, I don't think there is a
dependency problem here.
There is one (nothing in src/support should depend on anything in src), but
we had exactly the same discussion already, so I am not going to repeat the
argument
Abdelrazak Younes wrote:
> As long as support is a static library, I don't think there is a
> dependency problem here.
There is one (nothing in src/support should depend on anything in src), but
we had exactly the same discussion already, so I am not going to repeat the
arguments. This dependency
Lars Gullik Bjønnes wrote:
Why is this in lyx_main.C? And why is there an extern for this in
support/unicode.h?
Because I wanted to have a single location for all singletons access and
creation.
(This just seems so backwards, and dependencies are going the wrong
way.)
As long as support
Why is this in lyx_main.C? And why is there an extern for this in
support/unicode.h?
(This just seems so backwards, and dependencies are going the wrong
way.)
--
Lgb