> 3. add changes to 1.5/scons so that scons can automatically detect
> 1.4/1.5 and compile appropriately. That is to say, people who want
> scons for 1.4.x can copy development/scons from trunk and compile.
>
> I prefer method 3, giving the fast evolving nature of the current
> scons system. Any opinion?
My vote does not count much but 3 is a sensible thing to do. I am using
scons for lyx/qt3 right now and I can tell you that it compiles three
times as fast as autotools on windows.
I just submitted a scons-version-neutralization patch. Now, if the
mentioned trivial patch is applied to the lyx1.4 tree, one can copy
trunk/.../scons to 1.4branch/../development and compile 1.4 with
scons ... frontend=qt2
I basically added support for lyx1.4/qt2 frontend. I decided to
separate it although it is only one file apart from lyx1.5/qt3. I
will also add xform and gtk support later, and I hope that I do not
need to treat them separately for 1.4 and 1.5.
I call this patch version-neutralization since the only version
specific part is now changed to:
-PACKAGE_VERSION = '1.5.0svn'
+#
+# detect version of lyx
+# only 1.4.x has frontends/qt2
+if os.path.isdir(os.path.join(TOP_SRC_DIR, 'src', 'frontends', 'qt2')):
+ PACKAGE_VERSION = '1.4.2svn'
+else:
+ PACKAGE_VERSION = '1.5.0svn'
+
The frontend and boost/iostreams parts are automatically handled.
One bug though: When I pass CCFLAGS="-O3 -w" to scons, I see that the
options is just appended to the default options (-O2 -Wall), ex:
g++ -o release\common\frontends\qt3\QCommandBuffer.o -c -O3 -w -Wall -O2
What exactly do you mean? Do you want me to remove -O2 if -O3 is
passed? This sounds difficult.
Bo
