Re: Scons: almost there

I forgot to thank Abdel, who figured out the right libraries to link under mingw. His work on identifying *used* macros in config.h also helped a lot. Thanks again. Bo

Re: Scons: almost there

"Bo Peng" <[EMAIL PROTECTED]> writes: | | We are getting closer, I think. I still have to find time to make up | my mind about non/auto/"". | | Patience ;) | And you clearly showed that you had no patience. | I just submitted another patch. With it, one can | 0. scons

Re: Scons: almost there

Is the problem fixed or not? yes, But as pointed out, scons is not the only reason for renaming, (and I choose to propse a rename *after* scons fixes the problem.) Please no renaming in 1.4.x. Your decision is mine. Bo

Re: Scons: almost there

And you clearly showed that you had no patience. I heard that French people have >130 days of paid leave? It is not basic building I worry about. It is things like distcheck, gettext, pch, warnings, stdlib-debug, install, stage-dir etc. etc. that I worry about. These will be added on a one

Re: Debut of the scons-based build system for lyx

On Tue, May 09, 2006 at 01:34:36PM +0200, Abdelrazak Younes wrote: > Enrico Forestieri a écrit : > >On Mon, May 08, 2006 at 12:10:41PM -0500, Bo Peng wrote: > > > >>>I am letting the current build to be completed before doing anything > >>>else. I notice that the moc'ed files are being compiled

Fwd: Debut of the scons-based build system for lyx

It is utterly ridiculous that they are not able to spot the difference between .c and .C on Cygwin and they are able to on native Windows. The .C and .c problem has been handled. Please, if you can, help me figure out why cygwin build lyx needs zlib1.dll, instead of cygwin libz.a. It seems

Re: Debut of the scons-based build system for lyx

Enrico Forestieri a écrit : On Tue, May 09, 2006 at 01:34:36PM +0200, Abdelrazak Younes wrote: Are you saying that .C files are recognized as C++ sources for you? Yes. IIRC scons call gcc for .C file and g++ for linking. That works perfectly. Abdel.

Re: Scons: almost there

Bo Peng a écrit : I just submitted another patch. With it, one can 0. scons directly under linux + lyx qt3/qt4 ... (state of yesterday) 1. scons directly using mingw + lyx qt3/4 + official zlib1.dll in a visible place I have an idea for you Bo. Instead of specifying

Re: Fwd: Debut of the scons-based build system for lyx

On Tue, May 09, 2006 at 08:56:52AM -0500, Bo Peng wrote: > >It is utterly ridiculous that they are not able to spot the difference > >between .c and .C on Cygwin and they are able to on native Windows. > > The .C and .c problem has been handled. So, is the problem with "undefined reference to

Re: Scons: almost there

I have an idea for you Bo. Instead of specifying "extra_inc_path=d:/mingw/include extra_lib_path=d:/mingw/lib" it would be better to specify "with_mingw=d:/mingw". Then Scons could add automatically the include and lib paths. _And_ Scons could search the required dll in "d:/mingw/bin/". Agreed.

Re: Fwd: Debut of the scons-based build system for lyx

> The .C and .c problem has been handled. So, is the problem with "undefined reference to vtable" solved? Yes. scons scans .cpp (and .cxx etc) and included .h files for Q_OBJECT, and moc them if needed. It failed to moc .C files because it is .c under windows. I have corrected the problem by

Re: Scons: almost there

> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes: >> And you clearly showed that you had no patience. Bo> I heard that French people have >130 days of paid leave? Lars is not french, you know. And some french people have families and choose to spend their week-ends with them. And yes, I have >

Re: Debut of the scons-based build system for lyx

Bo didn't asked on Friday in the middle of our great battle? If not, sorry for that. Bo, say sorry to JMarc too please :-) OK. I aplogize, although there is a draft email I wrote yesterday, trying to vent my own anger. Bo

Re: Debut of the scons-based build system for lyx

Could I suggest that you list the initial features that you want so that scons stays in SVN? Lars wants an immediate replacement for autotools. That will not happen any time soon. It seems to me that scons is already capable of building a linux executable albeit without client support. Am I

Re: Debut of the scons-based build system for lyx

Jean-Marc Lasgouttes wrote: Joost> If compilation with MSVC++ worked, the vcproj files would be Joost> very useful. However, there are still incompatibilities that Joost> break important things. It used to work. What is broken now? With some hacks to the projects files you can probably

Re: [Patch] reduce linking time under windows

> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: Joost> Abdelrazak Younes wrote: >>> Why is this still not in? Without this patch, dynamic linking with >>> Q../Free takes hours. >> You mean in 1.4? That's JMarc'c call. Joost> Yes, it should definitely go in 1.4 as well. I have used it

Re: [Patch] reduce linking time under windows

Jean-Marc Lasgouttes wrote: Joost> Yes, it should definitely go in 1.4 as well. I have used it for Joost> some time while working on the new Windows installer, it works Joost> fine. Can I see the patch again? Here it is. Joost Index: config/cygwin.m4

Re: Scons: almost there

And yes, I have > 130 days of paid leave :) If finding a job in French is easy, I will try to go there. Bo> These will be added on a one by one basis. The advantage of scons Bo> is that (almost) anyone can read SConstruct and add the feature he Bo> wants. I *will not* add every single feature

Re: [PATCH] do not configure in system_support directory

> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: Joost> Jean-Marc Lasgouttes wrote: Look how it is done in the Joost> Reconfigure function in lyx_cb.C. >> That is what I did at first, and I came up with the attached. Joost> Great, finally it works fine! Please put it in. I did so.

Re: 1.4.2svn fails to read lyxrc.defaults

> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes: Bennett> On May 2, 2006, at 10:03 AM, Jean-Marc Lasgouttes wrote: >>> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes: >> Michael> Hi, when running LyX 1.4.2svn, I get the following error Michael> message: Michael> Error while

Re: Fwd: Debut of the scons-based build system for lyx

On Tue, May 09, 2006 at 10:19:39AM -0500, Bo Peng wrote: > >> The .C and .c problem has been handled. > > > >So, is the problem with "undefined reference to vtable" solved? > > Yes. scons scans .cpp (and .cxx etc) and included .h files for > Q_OBJECT, and moc them if needed. It failed to moc .C

Re: Debut of the scons-based build system for lyx

On Tue, May 09, 2006 at 04:38:14PM +0200, Abdelrazak Younes wrote: > Enrico Forestieri a écrit : > >On Tue, May 09, 2006 at 01:34:36PM +0200, Abdelrazak Younes wrote: > > > >Are you saying that .C files are recognized as C++ sources for you? > > Yes. IIRC scons call gcc for .C file and g++ for

Re: Scons: almost there

On Tue, May 09, 2006 at 10:09:11AM -0500, Bo Peng wrote: > >I have an idea for you Bo. Instead of specifying > >"extra_inc_path=d:/mingw/include extra_lib_path=d:/mingw/lib" it would > >be better to specify "with_mingw=d:/mingw". Then Scons could add > >automatically the include and lib paths.

Re: Fwd: Debut of the scons-based build system for lyx

Yes, python should be easier to tweak than m4, but we have to prove that it can be as powerful as m4 is. For (almost?) all the autoconf stuff, I have implemented them in python without problem. It is easier (?) and cleaner (yes!) than m4. As I have said, scons is currently weak on "make dist"

Re: Scons: almost there

Using scons it takes only 2/3 of the time needed using auto* stuff for me on cygwin. But it seems that I cannot convince scons to compile using -O2 so, I am sorry, but the comparison is unfair. So you mean you succeed? Great to know. Before I figure out how to pass -O3, you can edit line 707

Re: Debut of the scons-based build system for lyx

I start thinking that scons is too much Windows centric... Oooh? It worked without any trouble on linux, and I spent several days to fix it for windows. You call this windows centric? Of couse, you can call autotools *nix cantric since they rely on sh/sed etc. Bo

Re: [Patch] reduce linking time under windows

> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: Joost> Jean-Marc Lasgouttes wrote: Yes, it should definitely go in 1.4 Joost> as well. I have used it for some time while working on the new Joost> Windows installer, it works fine. >> Can I see the patch again? Joost> Here it is.

Re: Debut of the scons-based build system for lyx

> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: Joost> For example, the MinGW implementations of functions to call Joost> other applications often do not show a console window, while Joost> the Microsoft implementation does. This means that you get Joost> popping up windows all the

Re: Scons: almost there

> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes: Bo> I know. scons lacks of a huge library of such things. I actually Bo> copied the SELECT_ARG thing from the autoconf source code. OK. So the big problem would be to make gettext fit in? >> Is there hope to avoid requiring installing SCons

Re: Comparison between scons and autotools.

Bo Peng a écrit : Dear list, *Please* just put cold comparison data in this thread. No discussion and debates. (Open another thread if needed). On my dual processor Xeon 2.8G Linux workstation, I get scons --config=force -j3 frontend=qt4 qt_dir=/path/to/qt4 => 6:37s autogen.sh;

Re: [Patch] reduce linking time under windows

Jean-Marc Lasgouttes wrote: Thanks. So the following (plus removal of cygwin.m4) would be just as good, right? Yes, but add a new file called windows.m4. My font patch for example needs to link against gdi32 on Windows. Joost

Re: [Patch] reduce linking time under windows

Jean-Marc Lasgouttes a écrit : "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: Joost> Jean-Marc Lasgouttes wrote: Yes, it should definitely go in 1.4 Joost> as well. I have used it for some time while working on the new Joost> Windows installer, it works fine. Can I see the patch again?

Re: Debut of the scons-based build system for lyx

Jean-Marc Lasgouttes wrote: This means we should use something else than system() for running programs, right? Or add proper options when in Systemcall? This would be a good thing to do anyway. If I remember correctly, the forkedcall stuff is the problem, not system(). Joost

Re: Debut of the scons-based build system for lyx

This means we should use something else than system() for running programs, right? Or add proper options when in Systemcall? This would be a good thing to do anyway. Exactly, under windows, use one of the process APIs. Bo

Re: Scons: almost there

> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes: Bo> Waf also claims to cache initial thinking process so null build Bo> (Lars reported a number around 24s) should be shorter there. Especially since null build are known to be very bad with recursive makefiles like we are using here. So a good

Re: Fwd: Debut of the scons-based build system for lyx

On Tue, May 09, 2006 at 11:08:21AM -0500, Bo Peng wrote: > Please, go to src/SConscript line 171 and move 'SYSTEM_LIBS' after > 'BOOST_LIBS'. This should solve the link problem, if it is caused by > -lz ordering (linux/g++, mingw do not care). Confirmed. Ordering matters. This is the only

Re: [Patch] reduce linking time under windows

On Tue, May 09, 2006 at 05:33:51PM +0200, Jean-Marc Lasgouttes wrote: > > "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: > > Joost> Abdelrazak Younes wrote: > >>> Why is this still not in? Without this patch, dynamic linking with > >>> Q../Free takes hours. > >> You mean in 1.4? That's

Re: Debut of the scons-based build system for lyx

On Tue, May 09, 2006 at 11:14:43AM -0500, Bo Peng wrote: > >I start thinking that scons is too much Windows centric... > > Oooh? It worked without any trouble on linux, and I spent several days > to fix it for windows. You call this windows centric? Of couse, you > can call autotools *nix cantric

Re: Fwd: Debut of the scons-based build system for lyx

because I asked for aspell support when configuring (I presume that it is not possible to have aspell at the moment). Not now. Please wait till we have the basics done. BTW, how can I add "-O2" to the compiler flags? I tried CPPFLAGS=-O2 on the command line, and also "export CPPFLAGS=-O2",

Re: 1.4.2svn fails to read lyxrc.defaults

On May 9, 2006, at 11:44 AM, Jean-Marc Lasgouttes wrote: "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes: Bennett> On May 2, 2006, at 10:03 AM, Jean-Marc Lasgouttes wrote: "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes: Michael> Hi, when running LyX 1.4.2svn, I get the

Slow starting of scons...

Dear all, It is now clear that scons can cut down overall building time by 1/3 or even 1/2, but a trivial null build will take from 24s to 4m. This is because scons is an 'overall' build process. It gathers all file information (checking contents rather than time stamp) and decide what to do.

Re: Comparison between scons and autotools.

On Tue, May 09, 2006 at 06:24:42PM +0200, Abdelrazak Younes wrote: > Bo Peng a écrit : > >Dear list, > > > >*Please* just put cold comparison data in this thread. No discussion > >and debates. (Open another thread if needed). > > > >On my dual processor Xeon 2.8G Linux workstation, I get > > >

Re: Debut of the scons-based build system for lyx

Abdel said that scons is able to recognize .C files as C++ source files on a native Windows environment. Why it is not able to do so with cygwin? I did not read that email in detail, what I know is that gcc tells the content of a .c file and make itself g++ if the file is indeed in C++.

Re: [PATCH] CT cleanup - 3rd round

John Levon wrote: I understand that sometimes that's difficult to do, and it's fair enough. But it's very important that the trunk stay working. What if someone else needs to make a related change, and they are completely blocked behind your work because the trunk's broken? What if you're

Re: Scons: almost there

On Tue, May 09, 2006 at 11:11:39AM -0500, Bo Peng wrote: > >Using scons it takes only 2/3 of the time needed using auto* stuff > >for me on cygwin. But it seems that I cannot convince scons to compile > >using -O2 so, I am sorry, but the comparison is unfair. > > So you mean you succeed? Great to

Re: [PATCH] CT cleanup - 3rd round

On Tue, May 09, 2006 at 06:28:58PM +0200, Michael Gerz wrote: > I will create a branch now. I will send small patches to the mailing > list and ask you for comments on the overall approach. However, I won't > care about a broken CT until it is time to merge with the trunk. Sounds great. john

Re: Scons: almost there

BTW what's the problem with aspell? I mean, it seems that "spell=aspell" fails in the final link step (even adding by hand -laspell). I added that option, and I have spell libraries checked, but did not add the libraries in. (search spell in SConstructt) Bo

Re: Scons: almost there

On Tue, May 09, 2006 at 11:11:39AM -0500, Bo Peng wrote: > Before I figure out how to pass -O3, you can edit line 707 of > Sconstruct and add things like ['O3']. (Not tested) This one did the trick: --- SConstruct.orig 2006-05-09 16:29:42.0 +0200 +++ SConstruct 2006-05-09

Re: Scons: almost there

--- SConstruct.orig 2006-05-09 16:29:42.0 +0200 +++ SConstruct 2006-05-09 19:24:12.0 +0200 @@ -706,7 +706,7 @@ if ARGUMENTS.get('mode', default_build_mode) == 'debug': env.Append(CCFLAGS = []) else: - env.Append(CCFLAGS = []) + env.Append(CCFLAGS = ['-O2']) Is this

Re: [Patch] reduce linking time under windows

On Tue, May 09, 2006 at 06:29:59PM +0200, Joost Verburg wrote: > Jean-Marc Lasgouttes wrote: > >Thanks. So the following (plus removal of cygwin.m4) would be just as > >good, right? > > Yes, but add a new file called windows.m4. My font patch for example > needs to link against gdi32 on Windows.

Re: Scons: almost there

On Tue, May 09, 2006 at 12:41:26PM -0500, Bo Peng wrote: > >--- SConstruct.orig 2006-05-09 16:29:42.0 +0200 > >+++ SConstruct 2006-05-09 19:24:12.0 +0200 > >@@ -706,7 +706,7 @@ > > if ARGUMENTS.get('mode', default_build_mode) == 'debug': > > env.Append(CCFLAGS = []) > >

Re: proposal for testing procedure of future LyX releases

On Tue, 9 May 2006, Uwe Stöhr wrote: > [EMAIL PROTECTED] wrote: > > > I think it's probably unrealistic to create and maintain a big archive > > with all of this. However, I'm sure few of you will be surprised when I'm > > now going to suggest how we partially use the wiki for helping with this.

Re: proposal for testing procedure of future LyX releases

On Tue, 9 May 2006, Uwe Stöhr wrote: > We could have automated tests but many things must be tested manually. > For example my math manual is build upon sequences to create a formula, > e.g. the sequence: > A_u uparrow ^2 > should create an "A" with the subscript "u" and the superscript "2". To

Re: Comparison between scons and autotools.

And you compiled using -O2 with scons, too, right? Otherwise this is an unfair comparison. I have numbers close to yours on cygwin, but I cannot convince scons to compile using -O2. With scons CCFLAGS=-O2, the compile time are about the same. This is not surprising since the core command g++

Re: proposal for testing procedure of future LyX releases

On 9 May 2006, Lars Gullik Bjønnes wrote: > When it comes to testing I will also put forward my meager attempt on > beginnging to create test cases (please expand on them and create new > ones). > > So far only for a few helper functions, but we should be able to do it > for larger subsystems as

Re: Fwd: Debut of the scons-based build system for lyx

On Tue, May 09, 2006 at 10:19:39AM -0500, Bo Peng wrote: > >> The .C and .c problem has been handled. > > > >So, is the problem with "undefined reference to vtable" solved? > > Yes. scons scans .cpp (and .cxx etc) and included .h files for > Q_OBJECT, and moc them if needed. It failed to moc .C

Re: LyX 1.4 and Windows 98/ME

On Mon, May 08, 2006 at 11:31:29PM +0200, Joost Verburg wrote: > Andre Poenitz wrote: > >Right, and it took two years or so to change that. > > > >I don't think you'd be much faster than Angus _even if > >everybody agreed_. > > OK, so the only remaining possibility is to drop Win98/Me support.

Re: Debut of the scons-based build system for lyx

On Mon, May 08, 2006 at 10:35:34PM +0200, Abdelrazak Younes wrote: > >>>I do welcome the effort to see if the current build system is > >>> > >>I don't think your wording is very welcoming, to quote you: "I hate it > >>already", "please revert", "I don't care one iota", etc... > >> > >>I

Re: Comparison between scons and autotools.

On Tue, May 09, 2006 at 12:48:16PM +0200, Lars Gullik Bjønnes wrote: > "Bo Peng" <[EMAIL PROTECTED]> writes: > > | Dear list, > | > | *Please* just put cold comparison data in this thread. No discussion > | and debates. (Open another thread if needed). > | > | On my dual processor Xeon 2.8G

Re: Debut of the scons-based build system for lyx

On Mon, May 08, 2006 at 11:19:49PM +0200, Joost Verburg wrote: > Andre Poenitz wrote: > >Last time the Windows developers wanted to have .vcproj files. > > > >They got them. > > If compilation with MSVC++ worked, the vcproj files would be very > useful. However, there are still incompatibilities

Re: [PATCH] CT cleanup - 3rd round

On Tue, May 09, 2006 at 12:07:32AM +0200, Michael Gerz wrote: > Please have a look at the patch and tell me whether it is OK. Its > overall objective is to make things simpler and clearer. I am not too happy about the additional #include in insetbase.h, but as I've never really timed LyX

Re: Slow starting of scons...

On Tue, May 09, 2006 at 12:04:44PM -0500, Bo Peng wrote: > I am too new to scons to give a full solution here. Here are some of > my opinions: > > 1. The check content (md5) approach is better than autotools since > time stamp can be easily changed and may trigger unnecessary rebuilds. Well, if

Re: [PATCH] CT cleanup - 3rd round

On Mon, May 08, 2006 at 11:57:24PM +0100, John Levon wrote: > On Tue, May 09, 2006 at 12:07:32AM +0200, Michael Gerz wrote: > > > I must confess that this patch will break CT in some cases > > Why is there such pushback against making branches for stuff that's > *known* broken? Because

Re: [PATCH] CT cleanup - 3rd round

On Tue, May 09, 2006 at 11:21:04AM +0200, Georg Baum wrote: > John and Lars, > > you both did not directly answer Michaels question. So what should he do > now? IMHO a simple "yes", "no", or "yes, but only in a separate branch" > would be in order. I am neither John nor Lars, but if Micheal has

Re: Fwd: Debut of the scons-based build system for lyx

On Tue, May 09, 2006 at 11:08:21AM -0500, Bo Peng wrote: > Vim is *the* editing tool for me. *You can tell from the first line of > every SCons* files). Why is this needed btw? Can't you use autocmd for it? Andre'

Re: Comparison between scons and autotools.

On Mon, May 08, 2006 at 04:35:01PM -0500, Bo Peng wrote: > Dear list, > > *Please* just put cold comparison data in this thread. No discussion > and debates. (Open another thread if needed). > > On my dual processor Xeon 2.8G Linux workstation, I get > > scons --config=force -j3 frontend=qt4

Re: Comparison between scons and autotools.

The second column is bad. Developers certainly spend more time on near 'null-builds' than on full rebuilds. I agree. I have posted an email to the scons-list. Let us see what they think about it. Cheers, Bo

C++ help wanted

Hi folks, could somebody please tell me why this piece of code compiles: bool const show_change = par.lookupChange(cur.pos()) != Change::UNCHANGED; as we have this class Change { public: /// the type of change enum Type { UNCHANGED, // no change

Re: C++ help wanted

Michael Gerz wrote: Hi folks, could somebody please tell me why this piece of code compiles: bool const show_change = par.lookupChange(cur.pos()) != Change::UNCHANGED; as we have this class Change { public: /// the type of change enum Type {

Re: Comparison between scons and autotools.

On Tue, May 09, 2006 at 02:59:38PM -0500, Bo Peng wrote: > >And you compiled using -O2 with scons, too, right? Otherwise this is > >an unfair comparison. I have numbers close to yours on cygwin, but I > >cannot convince scons to compile using -O2. > > With scons CCFLAGS=-O2, the compile time are

Re: Slow starting of scons...

On Tue, May 09, 2006 at 10:00:51PM +0200, Andre Poenitz wrote: > On Tue, May 09, 2006 at 12:04:44PM -0500, Bo Peng wrote: > > I am too new to scons to give a full solution here. Here are some of > > my opinions: > > > > 1. The check content (md5) approach is better than autotools since > > time

Re: [PATCH] CT cleanup - 3rd round

On Tue, May 09, 2006 at 09:19:17PM +0200, Andre Poenitz wrote: > > > I must confess that this patch will break CT in some cases > > > > Why is there such pushback against making branches for stuff that's > > *known* broken? > > Because maintaining branches is an extra effort that eats

[PATCH] CT, part 4

Hello, the following patch for my personal branch decouples the tracking of changes from the output of changes, i.e., you can turn both on and off at any time. The patch will also enable (once the LyX core is fixed) accepting/rejecting changes even if ct is switched off. I assume that

Re: Comparison between scons and autotools.

On Tue, May 09, 2006 at 10:57:29PM +0200, Enrico Forestieri wrote: > I had just compiled successfully with aspell support when I saw your > new commit. I still think that the attached patch is necessary. Hmmm... I blindly applied my patch over your new commit without reading it. Please, note the

Re: [PATCH] CT, part 4

On Tue, May 09, 2006 at 10:27:17PM +0200, Michael Gerz wrote: > case LFUN_CHANGE_REJECT: // what about these two > case LFUN_ALL_CHANGES_ACCEPT: > case LFUN_ALL_CHANGES_REJECT: > - flag.enabled(buffer_ && buffer_->params().tracking_changes); > +

Re: [PATCH] CT, part 4

John Levon wrote: On Tue, May 09, 2006 at 10:27:17PM +0200, Michael Gerz wrote: case LFUN_CHANGE_REJECT: // what about these two case LFUN_ALL_CHANGES_ACCEPT: case LFUN_ALL_CHANGES_REJECT: - flag.enabled(buffer_ && buffer_->params().tracking_changes);

Re: [PATCH] CT, part 4

On Tue, May 09, 2006 at 10:52:27PM +0200, Michael Gerz wrote: > >>case LFUN_CHANGE_REJECT: // what about these two > >>case LFUN_ALL_CHANGES_ACCEPT: > >>case LFUN_ALL_CHANGES_REJECT: > >>- flag.enabled(buffer_ && buffer_->params().tracking_changes); > >>+

Re: Comparison between scons and autotools.

Hmmm... I blindly applied my patch over your new commit without reading it. Please, note the "appnend" typo. Yes. That is a ugly one. I will fix that one with others. Now, I think I can claim that scons is *basically* working. It is already a straight 'scons' for linux, mingw and cygwin. The

Re: [PATCH] CT, part 4

John Levon wrote: No. The test has been removed on purpose. In fact, the major motivation of the CT code changes is the user requirement to switch CT off without having to accept all changes before. I know. Read what I wrote :) These should be disabled if there's nothing /to/ reject or

Re: [PATCH] CT, part 4

On Tue, May 09, 2006 at 11:06:58PM +0200, Michael Gerz wrote: > >These should be disabled if there's nothing /to/ reject or accept. If > >that's too hard or slow to do then OK, but we should try. > > > I will send you a screenshot tomorrow. Right now, my tree is broken. > Actually, my plans are

Re: Debut of the scons-based build system for lyx

On Mon, May 08, 2006 at 10:57:12AM -0500, Bo Peng wrote: > >It should not be in svn beforee it at least can compile linux > >trivially. > > And it will work trivially under windows soon, if more testing, as a > result of more publicity is allowed. I guarantee you that it will > achieve a state of

Re: Slow starting of scons...

Word from the master of waf: Thomas Nagy (Applause, please) * Adding '#include "foo.moc"' at the end of 'foo.C' will reduce compilation times by 30-40% on the average. The old scheme will not be supported in Waf and i believe scons now supports the foo.moc scheme too. ## Bo: Does anydoby know

[PATCH] CT 5

Hi, just too many things happended implicitly in the CT code. Attached please find a rather boring cleanup for my personal CT branch. Michael Index: paragraph.h === --- paragraph.h (Revision 13819) +++ paragraph.h (Arbeitskopie)

Re: [PATCH] CT 5

On Wed, May 10, 2006 at 12:01:46AM +0200, Michael Gerz wrote: > just too many things happended implicitly in the CT code. Seems OK john

Re: Comparison between scons and autotools.

On Tue, May 09, 2006 at 02:59:38PM -0500, Bo Peng wrote: > spell checker and aikasurus are > supposed to work now. The spell checker works, but, although the Aiksaurus library is indeed linked in, I am missing the Thesaurus entry in the Tools menu. Many things should still be tuned, among them:

Re: Comparison between scons and autotools.

On Tue, May 09, 2006 at 04:44:47PM -0500, Bo Peng wrote: > >Hmmm... I blindly applied my patch over your new commit without > >reading it. Please, note the "appnend" typo. > > Yes. That is a ugly one. I will fix that one with others. Ok, Thanks. > Now, I think I can claim that scons is

Re: C++ help wanted

Michael Gerz <[EMAIL PROTECTED]> writes: > > Since when is it allowed to compare an object with an enum??? > I found it out by myself: The enum is a constructor argument, i.e., it > is converted into an object. Very ugly. Sounds like you should add the explicit keyword to the constructor...

Re: [PATCH] CT 5

On Wed, 2006-05-10 at 00:01 +0200, Michael Gerz wrote: > Hi, > > just too many things happended implicitly in the CT code. > > Attached please find a rather boring cleanup for my personal CT branch. Yes, way more readable, less guesswork. I wish I had time to check out your branch and try for

Re: Comparison between scons and autotools.

On Tue, May 09, 2006 at 04:44:47PM -0500, Bo Peng wrote: > Now, I think I can claim that scons is *basically* working. It is > already a straight 'scons' for linux, mingw and cygwin. And now solaris, too. I start liking this scons thing ;-) Please, attached find a patch fixing compilation with

Re: Comparison between scons and autotools.

Please, attached find a patch fixing compilation with aiksaurus and some other small thing. All look reasonable. Will be applied. Please, have a look at version.C.in as there are a couple of strings ("@PACKAGE_VERSION@" and "@VERSION_INFO@") that are not substituted when generating version.C.

Re: [PATCH]

Abdelrazak Younes wrote: But that's my point, one should not have to recompile everything because of a single setting change that impact the compilation of a single file. If you know that it should only recompile a single file or two, then just touch the object files first, and then touch the

Re: [PATCH] CT 5

Martin Vermeer wrote: Yes, way more readable, less guesswork. I wish I had time to check out your branch and try for myself... no chance until next week. The branch is broken anyway and it does not include all available patches. The situation will be better next week. Michael

<    1   2   3