Re: [PATCH] Allow to build several frontends in the same tree
Jean-Marc Lasgouttes wrote: > Indeed. Try again. Like a charm. Thanks, Alfredo
cvs graphics include error
Hi all, There seems to be an error with floats in current 1.4.0 cvs. Only the first figure is used. i.e., if I have a float with figure1.eps, and a later float with figure2.eps, then the result from view->ps will show figure1.eps for both floats. The view in lyx is correct. Here is the command line output, when doing view->ps ~/docs/art-emb-cyl$ This is dvips(k) 5.92b Copyright 2002 Radical Eye Software (www.radicaleye.com) ' TeX output 2003.08.04:1249' -> newfile2.ps . [1] [2 ] [3 ] Rod _ rod | "Beneath the waves, the waves / That's where I will be / | I'm going to see the cow beneath the sea." | They Might Be Giants, Lincoln
Re: elsart.layout
> Rod> It appeared to have been merged badly. There were some extra dash > Rod> and <<< characters floating around. So essentially, it is the > Rod> patch done correctly. No change in functionality. > > Maybe is it because I adjusted the spacing and rewrote Elseveir as > Elsevier. Basically I think it is correct. > > JMarc My humblest apologies...I seemed to have once again been baffled by CVS. After doing an update/make, the elsart.layout file I ended up with didn't work, and had extra - and < bits in it. Deleting the file, and updating again seems to have resulted in a working elsart file. Sorry about that. Rod _ rod | "Beneath the waves, the waves / That's where I will be / | I'm going to see the cow beneath the sea." | They Might Be Giants, Lincoln
Re: [PATCH] Allow to build several frontends in the same tree
Alfredo Braunstein wrote: Thanks, now it compiles frontends/qt2 just fine. --with-frontend='qt xforms' I get now: Making all in forms Indeed. Try again. JMarc
[PATCH] More architectural changes to tex2lyx
The following patch reimplements some of the stuff I wrote in chemnitz
to handle document structure. There is now a nice Context structure
which is passed around and replaces a few silly global variables.
This even supports some basic nesting, but everything does not work yet.
I plan to work more on this next week.
Andre', OK to apply?
JMarc
? src/tex2lyx/test.tex
Index: src/tex2lyx/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/tex2lyx/ChangeLog,v
retrieving revision 1.27
diff -u -r1.27 ChangeLog
--- src/tex2lyx/ChangeLog 30 Jul 2003 14:41:59 - 1.27
+++ src/tex2lyx/ChangeLog 3 Aug 2003 22:24:56 -
@@ -1,3 +1,26 @@
+2003-08-03 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * text.C: update to use Context struct, and more notably:
+ (cap, check_layout, check_end_layout): remove
+ (parse_text_snippet): new thin wrapper around parse_text, used for
+ things like \textrm{...}
+ (parse_environment): remove existing depth handling code, which is
+ handled transparently by the Context struct; make unknown
+ environments work (again?) through ERT
+
+ * test-structure.tex: new test file, used to try out various
+ layouts combinations
+
+ * tex2lyx.C:
+ * tex2lyx.h:
+ * table.C: update to use Context struct
+
+ * context.[Ch]: new helper struct which is passed to parse_*
+ functions and handles *_layout and *_deeper tags output
+
+ * Makefile.am (EXTRA_DIST): new file test-structure.tex
+ (tex2lyx_SOURCES): add context.[Ch]
+
2003-07-30 Angus Leeming <[EMAIL PROTECTED]>
* Makefile.am: Hide the fact that we re-generate those symbolic links
Index: src/tex2lyx/Makefile.am
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/tex2lyx/Makefile.am,v
retrieving revision 1.11
diff -u -r1.11 Makefile.am
--- src/tex2lyx/Makefile.am 30 Jul 2003 14:41:27 - 1.11
+++ src/tex2lyx/Makefile.am 3 Aug 2003 22:24:56 -
@@ -1,6 +1,7 @@
include $(top_srcdir)/config/common.am
INCLUDES = -I$(srcdir)/../ $(BOOST_INCLUDES)
+EXTRA_DIST = test-structure.tex
#noinst_LTLIBRARIES = libtexparser.la
#
@@ -27,6 +28,8 @@
tex2lyx_SOURCES = \
$(linked_files) \
Spacing.h \
+ context.C \
+ context.h \
gettext.C \
gettext.h \
lyxfont.C \
Index: src/tex2lyx/context.C
===
RCS file: src/tex2lyx/context.C
diff -N src/tex2lyx/context.C
--- /dev/null 1 Jan 1970 00:00:00 -
+++ src/tex2lyx/context.C 3 Aug 2003 22:24:56 -
@@ -0,0 +1,79 @@
+/** A small helper function
+\author Jean-Marc Lasgouttes (2003)
+ */
+
+#include
+
+#include "context.h"
+
+using std::ostream;
+using std::endl;
+
+Context::Context(bool need_layout_,
+LyXTextClass const & textclass_,
+LyXLayout_ptr layout_, LyXLayout_ptr parent_layout_)
+ : need_layout(need_layout_),
+ need_end_layout(false), need_end_deeper(false),
+ textclass(textclass_),
+ layout(layout_), parent_layout(parent_layout_)
+{
+ if (!layout.get())
+ layout = textclass.defaultLayout();
+ if (!parent_layout.get())
+ parent_layout = textclass.defaultLayout();
+}
+
+
+void Context::check_end_layout(ostream & os)
+{
+ if (need_end_layout) {
+ os << "\n\\end_layout\n";
+ need_end_layout = false;
+ }
+ if (need_end_deeper) {
+ os << "\n\\end_deeper\n";
+ need_end_deeper = false;
+ }
+}
+
+
+void Context::check_layout(ostream & os)
+{
+ if (need_layout) {
+ if (parent_layout->isEnvironment()) {
+ if (need_end_deeper) {
+ // no need to have \end_deeper \begin_deeper
+// FIXME: This does not work because \par already calls check_end_layout
+ need_end_deeper = false;
+ check_end_layout(os);
+ } else {
+ check_end_layout(os);
+ os << "\n\\begin_deeper\n";
+ need_end_deeper = true;
+ }
+ } else
+ check_end_layout(os);
+
+ os << "\n\\begin_layout " << layout->name() << "\n\n";
+ need_end_layout = true;
+ need_layout=false;
+ if (!extra_stuff.empty()) {
+ os << extra_stuff;
+ extra_stuff.erase();
+ }
+ }
+}
+
+
+void Context::dump(ostream & os, string const & desc) const
+{
+ os << desc <<" [";
+ if (need_layout)
+ os << "need_layout ";
+ if (need_end_lay
curious fact
[EMAIL PROTECTED] src]$ ./lyx-xforms lyxlex: UNcompressed [...] lyxlex: UNcompressed BufferView::update() [EMAIL PROTECTED] src]$ ./lyx-qt lyxlex: UNcompressed [...] lyxlex: UNcompressed BufferView::update() BufferView::update() Yes, I am bored :) Alfredo
Re: [PATCH] Allow to build several frontends in the same tree
Jean-Marc Lasgouttes wrote: > I missed a makefile. Try again. Thanks, now it compiles frontends/qt2 just fine. --with-frontend='qt xforms' I get now: Making all in forms make[5]: Entering directory `/home/ab/lyx-cvs/build/src/frontends/xforms/forms' /bin/sh ../../../../../src/frontends/xforms/forms/fdfix.sh ../../../../../src/frontends/xforms/forms/form_aboutlyx.fd source='form_aboutlyx.C' object='form_aboutlyx.lo' libtool=yes \ depfile='.deps/form_aboutlyx.Plo' tmpdepfile='.deps/form_aboutlyx.TPlo' \ depmode=gcc3 /bin/sh ../../../../../config/depcomp \ /bin/sh ../../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../../../src/frontends/xforms/forms -I../../../../src -I../../../../../src/frontends/xforms/forms/.. -I../../../../../src -I.. -I/usr/X11R6/include -O -fno-exceptions -W -Wall -c -o form_aboutlyx.lo `test -f 'form_aboutlyx.C' || echo '../../../../../src/frontends/xforms/forms/'`form_aboutlyx.C g++ -DHAVE_CONFIG_H -I. -I../../../../../src/frontends/xforms/forms -I../../../../src -I../../../../../src/frontends/xforms/forms/.. -I../../../../../src -I.. -I/usr/X11R6/include -O -fno-exceptions -W -Wall -c form_aboutlyx.C -MT form_aboutlyx.lo -MD -MP -MF .deps/form_aboutlyx.TPlo form_aboutlyx.C:12:26: ../lyx_forms.h: No such file or directory form_aboutlyx.C: In function `FD_aboutlyx* build_aboutlyx(void*)': form_aboutlyx.C:24: `FL_NO_BOX' undeclared (first use this function) form_aboutlyx.C:24: (Each undeclared identifier is reported only once for each function it appears in.) form_aboutlyx.C:24: `fl_bgn_form' undeclared (first use this function) form_aboutlyx.C:25: invalid use of undefined type `struct forms_' ../../../../../src/frontends/xforms/forms_fwd.h:17: forward declaration of ` struct forms_' Alfredo
Re: [Patch] Branch, latest
On Fri, Aug 01, 2003 at 07:02:29AM +0300, Martin Vermeer spake thusly: ... > One remaining problem: the place where the colour is used in > insets/insetbranch.C where we have > > setBackgroundColor(lc.getFromGUIName(color)); > > 'color' being the string name. So, an LColor is being generated. Can > the colour picker handle that (i.e. add a legit LColor and name to the > database, where the above will find it) for an arbitrary RGB triplet? > I seem to remember this mentioned somewhere. Having analyzed this proble a little further, it looks pretty bad. The need by setBackgroundColor for an LColor can be traced back to fillRectangle in Painter and in XPainter, which calls XFillRectangle that takes a Graphics Context as argument... produced by (file ColorHandler.C) LyXColorHandler::getGCForeground(LColor::color c) ! Do I really have to start tinkering with this deep stuff, e.g., define a LyXColorHandler::getGCForeground() that takes an RGB argument? It would shortcircuit part of the code and would call XAllocColor directly. Am I on a wild goose chase? Martin ...and what about this getGCForeground routine... I wonder if it is perhaps unnecessarily complex. Especially as I have the following Questions: 1) shouldn't the statement at ColorHandler:C:118 be val.foreground = ccol.pixel; rather than the presumably cut'npasted val.foreground = xcol.pixel; ? 2) Does the ccol conditional block contribute anything? 3) Does the manual traversal of the colour space after that contribute anything, i.e., do a better job than XAllocColor itself? Why not use XAllocColor directly as it was made for this? - M. pgp0.pgp Description: PGP signature
Re: [PATCH] Allow to build several frontends in the same tree
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes: Alfredo> Nevertheless, it seems that this is not exactly the problem Alfredo> (I don't know why I've mentioned it in fact), because Alfredo> QT_INCLUDES=/usr/lib/qt-3.1/include is correctly defined in Alfredo> makefiles, even if it doesn't show up in the failing compile Alfredo> line. I missed a makefile. Try again. JMarc
Re: Question on lyx2lyx
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> Fixed. Should I commit it to the 1.3.x branch ? Yes please. JMarc
Re: [Patch] Branch, latest
On Fri, Aug 01, 2003 at 04:24:57PM +0200, Jean-Marc Lasgouttes spake thusly: ... > If I am allowed to be annoying (anyway this is friday...): > > --- src/lyxfunc.C 30 Jul 2003 15:34:47 - 1.473 > +++ src/lyxfunc.C 1 Aug 2003 13:38:22 - > @@ -636,6 +639,13 @@ FuncStatus LyXFunc::getStatus(FuncReques > break; > case LFUN_INSERT_NOTE: > code = InsetOld::NOTE_CODE; > + break; > + case LFUN_INSERT_BRANCH: > + code = InsetOld::BRANCH_CODE; > + if (buf) > + disable = buf->params.branchlist.allBranches().empty(); > + else > + disable = true; ... > Finally, it would be less costly to add a size() member to BranchList > and use that instead of generating a full list of branches in the > test. Or empty() ... I have now case LFUN_INSERT_BRANCH: code = InsetOld::BRANCH_CODE; if (buf->params.branchlist.empty()) disable = true; break; ... > JMarc Martin pgp0.pgp Description: PGP signature
Re: [PATCH] Allow to build several frontends in the same tree
On Sun, Aug 03, 2003 at 10:31:48AM +0200, Lars Gullik Bjønnes wrote: > "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: > > | On Sat, Aug 02, 2003 at 08:43:53PM +0200, Jean-Marc Lasgouttes wrote: > >> The following patch allows to compile several frontends in the same > >> tree. If one configures lyx with --with-frontends='qt xforms', for > >> example, the binaries lyx-qt and lyx-xforms are built, and lyx is > >> a symbolic link to lyx-qt. > >> > >> As it is now this is mostly a feature for developper, and not really > >> meant to install those different frontends (actually, only lyx gets > >> installed). > >> > >> I do not know either what should be done for RPM files. > > > | I think this is good but I don't think it should be done for RPM files. > > > | A single "./configure --with-frontend=foo" should create the lyx.spec > | file specific to the foo frontend. I don't think many people install > | multiple frontends. > > Perhaps not, but why not create RPM's lyx-xforms... lyx-qt... and > lyx-common then? > > So IMHO the lyx.spec should build all possible frontends. One problem I see with this approach: If the lyx-qt build fails, then all subsequent builds do not finish. Currently, lyx-qt build is separate from lyx-xforms, so the automated RPM build process can finish one and then the other on a daily basis. Hmmm... on the other hand, there is much merit to the lyx-xforms, lyx-qt, lyx-common and lyx-docs idea. Okay... The solution is this: the xforms.spec that is generated will only create multiple frontends if multiple frontends are mentioned in the initial ./configure line. This makes it possible for someone to generate a qt RPM even if they don't have xforms installed or vice versa. I can imagine something like this at the top of the spec file: %define build_qt_frontend 1 %define build_xforms_frontend 1 and then some %if ... sections in the spec file. The configure process would tweak these settings based on the frontends specified by the user. It could work. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: gzip support problems
On Sun, Aug 03, 2003 at 06:28:03PM +0200, Lars Gullik Bj?nnes wrote: > Yes "Save as compressed" should be rarely changed, so perfect fit. Rubbish, people will want to change it all the time. "I could do with it for my thesis, but not for my DocBook doc I need to feed through my_fixup_script.pl". btw, gzip is also broken for "Insert->File->Child Document" "Insert->File->LyX Document". The file dialogs do not show lyx.gz files. john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: gzip support problems
John Levon <[EMAIL PROTECTED]> writes: >> | 3) there is no UI to save a compressed version >> >> :-) Can be added... But there should not be a separate ui for this, >> imho a preference should do the job here. > | A preference is *definitely* not a right fit. Prefs should be rarely | changed. Yes "Save as compressed" should be rarely changed, so perfect fit. | Instead we need an Export entry or some such (ideally something | in the normal Save dialog) I do not agree. -- Lgb
Re: Spell as you type - on its way? (feature request)
On Sun, Aug 03, 2003 at 06:31:39PM +0200, Janus Sandsgaard wrote: > Speaking of spelling: Are there plan for implementing a kind of "spell as you > type" / "flyspell" in LyX? It would be a great and very usefull improvement. No plans. It's on bugzilla john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Spell as you type - on its way? (feature request)
Hi there Speaking of spelling: Are there plan for implementing a kind of "spell as you type" / "flyspell" in LyX? It would be a great and very usefull improvement. -j -- Janus Sandsgaard http://janus.dk
Re: gzip support problems
On Sun, Aug 03, 2003 at 05:53:34PM +0200, Lars Gullik Bj?nnes wrote: > | 1) you can't load or handle compressed files from a previous version of > |lyx. This is an important bug. > > That is a lyx2lyx problem, I thought Jose did something to support > this? Well it doesn't work. I just get "not a lyx doc". > | 2) I get from view->dvi: newfile3.lyx.tex.dviq: newfile3.lyx.tex.dviq: > | No such file or directory > > ?? Don't ask me. Doesn't happen without a compressed lyx file. > | 3) there is no UI to save a compressed version > > :-) Can be added... But there should not be a separate ui for this, > imho a preference should do the job here. A preference is *definitely* not a right fit. Prefs should be rarely changed. Instead we need an Export entry or some such (ideally something in the normal Save dialog) john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: gzip support problems
John Levon <[EMAIL PROTECTED]> writes: | 1) you can't load or handle compressed files from a previous version of |lyx. This is an important bug. That is a lyx2lyx problem, I thought Jose did something to support this? | 2) I get from view->dvi: newfile3.lyx.tex.dviq: newfile3.lyx.tex.dviq: | No such file or directory ?? | 3) there is no UI to save a compressed version :-) Can be added... But there should not be a separate ui for this, imho a preference should do the job here. -- Lgb
gzip support problems
1) you can't load or handle compressed files from a previous version of lyx. This is an important bug. 2) I get from view->dvi: newfile3.lyx.tex.dviq: newfile3.lyx.tex.dviq: No such file or directory 3) there is no UI to save a compressed version regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [PATCH] Allow to build several frontends in the same tree
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > | Lars> Perhaps not, but why not create RPM's lyx-xforms... lyx-qt... | Lars> and lyx-common then? > | This would make sense. and a separate lyx-docs as well. (this would also simplify the make file a bit...) | Lars> So IMHO the lyx.spec should build all possible frontends. > | Yes, but I do not know how to do that. quite easy. I have a couple of tasks that I am working on, when those are finished I will have time to look at this, so unless somebody beats me too it... -- Lgb
Re: [PATCH] Allow to build several frontends in the same tree
Jean-Marc Lasgouttes wrote: > So how is configure supposed to find the Qt includes? Using QT_DIR? No idea, but it just used to work (I've never explicited the include path in the configure line). Nevertheless, it seems that this is not exactly the problem (I don't know why I've mentioned it in fact), because QT_INCLUDES=/usr/lib/qt-3.1/include is correctly defined in makefiles, even if it doesn't show up in the failing compile line. What should I look into? I'm sort of clueless. Regards, Alfredo
Re: [PATCH] Allow to build several frontends in the same tree
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes: Alfredo> After an ./autogen.sh; mkdir build; cd build; ../configure \ Alfredo> --enable-maintainer-mode --disable-debug --with-frontend=qt Alfredo> I get the following: Alfredo> Note that there teh qt include path is not used in the Alfredo> configure line. So how is configure supposed to find the Qt includes? Using QT_DIR? JMarc
Re: [PATCH] Allow to build several frontends in the same tree
Jean-Marc Lasgouttes wrote:
> The following patch allows to compile several frontends in the same
> tree. If one configures lyx with --with-frontends='qt xforms', for
> example, the binaries lyx-qt and lyx-xforms are built, and lyx is
> a symbolic link to lyx-qt.
>
> As it is now this is mostly a feature for developper, and not really
> meant to install those different frontends (actually, only lyx gets
> installed).
>
> I do not know either what should be done for RPM files.
>
> I guess that there are still small problems here and there, but if there
> is no philosophical problem, I'd like to commit it now, so that we see
> what needs to be fixed. I do not know of any problem.
After an ./autogen.sh; mkdir build; cd build; ../configure \
--enable-maintainer-mode --disable-debug --with-frontend=qt
I get the following:
make[6]: Leaving directory `/home/ab/lyx-cvs/build/src/frontends/qt2/ui'
Making all in moc
make[6]: Entering directory
`/home/ab/lyx-cvs/build/src/frontends/qt2/ui/moc'
source='BiblioModuleBase_moc.C' object='BiblioModuleBase_moc.lo' libtool=yes
\
depfile='.deps/BiblioModuleBase_moc.Plo'
tmpdepfile='.deps/BiblioModuleBase_moc.TPlo' \
depmode=gcc3 /bin/sh /home/ab/lyx-cvs/config/depcomp \
/bin/sh ../../../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I.
-I/home/ab/lyx-cvs/src/frontends/qt2/ui/moc -I../../../../../src
-I/home/ab/lyx-cvs/src -I/home/ab/lyx-cvs/src/frontends
-I/home/ab/lyx-cvs/src/frontends/controllers -I/home/ab/lyx-cvs/boost
-I/usr/X11R6/include -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR
-DQT_NO_TRANSLATION -O -fno-exceptions -W -Wall -c -o
BiblioModuleBase_moc.lo `test -f 'BiblioModuleBase_moc.C' || echo
'/home/ab/lyx-cvs/src/frontends/qt2/ui/moc/'`BiblioModuleBase_moc.C
g++ -DHAVE_CONFIG_H -I. -I/home/ab/lyx-cvs/src/frontends/qt2/ui/moc
-I../../../../../src -I/home/ab/lyx-cvs/src
-I/home/ab/lyx-cvs/src/frontends
-I/home/ab/lyx-cvs/src/frontends/controllers -I/home/ab/lyx-cvs/boost
-I/usr/X11R6/include -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR
-DQT_NO_TRANSLATION -O -fno-exceptions -W -Wall -c BiblioModuleBase_moc.C
-MT BiblioModuleBase_moc.lo -MD -MP -MF .deps/BiblioModuleBase_moc.TPlo
In file included from BiblioModuleBase_moc.C:8:
../BiblioModuleBase.h:13:22: qvariant.h: No such file or directory
../BiblioModuleBase.h:14:21: qwidget.h: No such file or directory
In file included from BiblioModuleBase_moc.C:8:
../BiblioModuleBase.h:24: parse error before `{' token
../BiblioModuleBase.h:29: destructors must be member functions
../BiblioModuleBase.h:35: parse error before `protected'
../BiblioModuleBase.h:41: parse error before `protected'
Note that there teh qt include path is not used in the configure line.
Please tell me if I'm doing something wrong or if you need more information
of any kind.
Regards, Alfredo
Re: [PATCH] Allow to build several frontends in the same tree
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Perhaps not, but why not create RPM's lyx-xforms... lyx-qt... Lars> and lyx-common then? This would make sense. Lars> So IMHO the lyx.spec should build all possible frontends. Yes, but I do not know how to do that. JMarc
Re: [PATCH] Allow to build several frontends in the same tree
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes: Kayvan> A single "./configure --with-frontend=foo" should create the Kayvan> lyx.spec file specific to the foo frontend. I don't think many Kayvan> people install multiple frontends. It should be what happens right now. Actually if you specify "qt xforms" as frontend I think that it will put the qt frontend in a rpm which depends on xforms :( This is a loop ordering problem, but I am not sure it is worth fixing... JMarc
Re: [PATCH] Allow to build several frontends in the same tree
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | On Sat, Aug 02, 2003 at 08:43:53PM +0200, Jean-Marc Lasgouttes wrote: >> The following patch allows to compile several frontends in the same >> tree. If one configures lyx with --with-frontends='qt xforms', for >> example, the binaries lyx-qt and lyx-xforms are built, and lyx is >> a symbolic link to lyx-qt. >> >> As it is now this is mostly a feature for developper, and not really >> meant to install those different frontends (actually, only lyx gets >> installed). >> >> I do not know either what should be done for RPM files. > | I think this is good but I don't think it should be done for RPM files. > | A single "./configure --with-frontend=foo" should create the lyx.spec | file specific to the foo frontend. I don't think many people install | multiple frontends. Perhaps not, but why not create RPM's lyx-xforms... lyx-qt... and lyx-common then? So IMHO the lyx.spec should build all possible frontends. -- Lgb
