Re: Debut of the scons-based build system for lyx
Joost Verburg wrote: > If compilation with MSVC++ worked, the vcproj files would be very > useful. However, there are still incompatibilities that break important > things. Note that compilation with MSVC++ worked fine some months ago (version 2003 aka 7, not 6, that one is simply broken), and that the project files (although now outdated) are available in development/Win32. Georg
Re: [patch] Windows: Improved Font Loading
> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: Joost> Currently, LyX relies on the BaKoMa fonts to be installed as a Joost> system font in order to be able to display math. This is not a Joost> good thing, it of course requires administrator privileges to Joost> install a system font and thus LyX cannot be installed without Joost> these rights. Joost> The attached Windows-only patch (this one is against 1.4) Joost> solves this problem by loading these math fonts from Joost> Resources\fonts at startup. This is indeed a good idea. We already do that for Lyx/Mac. This is done currently in qt2/qfont_loader::initFontPath. Could you move the code there? I would also prefer to use private fonts in Win2k/xp also. When using AddFontResource, the docs say that one should do a SendMessage to give notice to other applications. I guess it is not needed with local fonts. Joost> The location of the code or style of the patch may not be Joost> completely right, feel free to change that. I'd appreciate if you could update the patch according to the remarks above, or find someone who can do so. JMarc
Re: proposal for testing procedure of future LyX releases
> "Uwe" == Uwe Stöhr <[EMAIL PROTECTED]> writes: Uwe> Personally I use a test procedure for every new release of my Uwe> LyXWinInstaller. Derived from this here's my proposal for new Uwe> releases of LyX: This would be very nice indeed. JMarc
Re: proposal for testing procedure of future LyX releases
[EMAIL PROTECTED] writes: | On Sun, 7 May 2006, [UTF-8] Uwe Stöhr wrote: | | > This email is a proposal for a new test procedure of LyX releases. | > | > In consequence of this I propose to create a testing procedure | > LyX-releases to avoid regressions and new introduced bugs. | | This makes a lot of sense to me. | | What John wrote about a place in the repository for storing test cases | also makes sense. | | In addition I think it will be worth the time to clearly document *how* | the testing can be done, so that hopefully non-coders can help with it. 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 well. should help us avoid (stupid) regressions. src/support/tests/ src/frontends/controllers/tests/ More of tests like this would be very welcome. And: test cases should be automatic if at all possible. So if we have to implement some new features in LyX to make that possible we should do so. And f.ex. a replay feature, could be greate for other stuff (demos?) as well. -- Lgb
Re: Debut of the scons-based build system for lyx
> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: Joost> Andre Poenitz wrote: >> Last time the Windows developers wanted to have .vcproj files. They >> got them. 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? JMarc
Re: [Fwd: Re: Debut of the scons-based build system for lyx]
On Monday 08 May 2006 18:43, Bo Peng wrote: > That is quicker than ./configure but I agree that it is a concern. waf > claims that it can do better here (by cache previous thinking > process.) I have seen you refer waf several times. Will those changes be merged in upstream scons? I read a blog from Aaron Seigo recently where we complained that kde had to basically fork scons and upstream never took their complains into account as opposed to cmake, and that was a definitive reason for their choice. Just curious, -- José Abílio
Re: Debut of the scons-based build system for lyx
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> You should have said something then. Because without Abdelrazak> anyone saying anything it's difficult to get an idea. 3 Abdelrazak> saying yes and 0 saying no... I think you get the picture. Say what? "please do not commit before showing the patch?" Do I have to say that explicitely on each and every feature I think someone may come up with some day? What would have been wrong with committing in a branch, seriously? The fact that these decisions are made only in terms of personal convenience makes it more difficult for scons to prove its personal merits. It is a pity. JMarc
Re: how to profile?
> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes: >> Martin Vermeer wrote: >> > On Sun, Apr 23, 2006 at 06:15:44PM +0200, Edwin Leuven wrote: >> > >> > /bin/sh ../libtool --tag=CXX --mode=link g++ -pg -g -O2 -pg -o > >> ... > g++ -pg -g -O2 -pg -o lyx-qt4 main.o Bidi.o BufferView.o >> >> Why these multiple -pg -g -pg options? Shouldn't prevent them from >> working (I think) but where do they come from? Edwin> because LDFLAGS = -pg gets added here on top of CXXFLAGS = -pg Edwin> -g -O2 I think the right solution would have been to add -pg to CXX directly. JMarc
Re: [PATCH] CT cleanup - 3rd round
John Levon <[EMAIL PROTECTED]> writes: | 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? I have no idea... it seems all my suggestions on using branches is put down without even trying. -- Lgb
Re: how to profile?
Jean-Marc Lasgouttes wrote: I think the right solution would have been to add -pg to CXX directly. although i didn't add it. i passed --enable-profile to ./configure ... so what would be the correct way to get this working? thanks, edwin
Re: how to profile?
Edwin Leuven <[EMAIL PROTECTED]> writes: | Jean-Marc Lasgouttes wrote: | > I think the right solution would have been to add -pg to CXX directly. | | although i didn't add it. i passed --enable-profile to ./configure | | ... | | so what would be the correct way to get this working? What do you mean? You configure with enable-profiling, you run lyx play with it, you run gprof to look at the generated profiling data. (found in gmon.out) -- Lgb
Re: how to profile?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes: | | >> Martin Vermeer wrote: | >> > On Sun, Apr 23, 2006 at 06:15:44PM +0200, Edwin Leuven wrote: | >> > | >> > /bin/sh ../libtool --tag=CXX --mode=link g++ -pg -g -O2 -pg -o > | >> ... > g++ -pg -g -O2 -pg -o lyx-qt4 main.o Bidi.o BufferView.o | >> | >> Why these multiple -pg -g -pg options? Shouldn't prevent them from | >> working (I think) but where do they come from? | | Edwin> because LDFLAGS = -pg gets added here on top of CXXFLAGS = -pg | Edwin> -g -O2 | | I think the right solution would have been to add -pg to CXX directly. Perhaps... or not to LDFLAGS. -- Lgb
Re: [PATCH] CT cleanup - 3rd round
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. Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> > writes: > > | 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? > > I have no idea... it seems all my suggestions on using branches is put > down without even trying. Maybe one reason for this is that people don't know how branches work exactly. Lars, from your commit messages I see that you follow a different procedure than I know from CVS times to update your branches. I guess everybody knows how to create a branch: svn copy svn+ssh://svn.lyx.org/lyx/lyx-devel/trunk svn+ssh://svn.lyx.org/lyx/lyx-devel/branches/mybranch but what is the preferred method to rebase it with trunk? The svn book is not very helpful here. It would be very nice if you could explain it with a few sentences. This could then be put in the wiki. Georg
Re: [PATCH] CT cleanup - 3rd round
On Tue, 2006-05-09 at 00:07 +0200, Michael Gerz wrote: > Folks, > > this is the next part of the CT cleanup. > > I must confess that this patch will break CT in some cases (but not > compilation, of course!). However, as I redesign the internal data > structures (change tracking is no longer an "add-on" but an integral > part of any paragraph and inset) it was impossible for me to find > another self-contained set of changes that can be applied without > breaking anything. I think we have to live with a broken CT for a week > or two now (depending on how fast you accept my incremental changes). > > Please have a look at the patch and tell me whether it is OK. Its > overall objective is to make things simpler and clearer. Precisely what breaks? I have no time right now to spend on LyX, but I think this should be fixed before checking in. Or perhaps this is the time to give 'feature branch' a try. - Martin signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: Debut of the scons-based build system for lyx]
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> John Levon a écrit : >> On Mon, May 08, 2006 at 04:19:29PM +0200, Abdelrazak Younes wrote: scons: Configure: Checking for main() in C library nsl... >>> What is this nsl library? >> It's networking functions on certain UNIX types like Solaris. Abdelrazak> Thanks for the info, it is used in LyX client I suppose? Also in server... I spend some time getting this right for solaris, please do not ruin it. And the X server needs it too, but I guess scons has some code of its own to handle that. JMarc
Re: Debut of the scons-based build system for lyx
Georg Baum a écrit : Joost Verburg wrote: If compilation with MSVC++ worked, the vcproj files would be very useful. However, there are still incompatibilities that break important things. Note that compilation with MSVC++ worked fine some months ago (version 2003 aka 7, not 6, that one is simply broken), and that the project files (although now outdated) are available in development/Win32. The problem with the vcproj file is the config.h guessing. This is simply not possible. I've read that scons is able now to generate these files so I would advocate to remove this vcproj file from SVN when/if Scons prove itself and stays in SVN. Abdel.
Re: [PATCH] CT cleanup - 3rd round
Georg Baum <[EMAIL PROTECTED]> writes: | 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. | | Lars Gullik Bjønnes wrote: | | > John Levon <[EMAIL PROTECTED]> | > writes: | > | > | 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? | > | > I have no idea... it seems all my suggestions on using branches is put | > down without even trying. | | Maybe one reason for this is that people don't know how branches work | exactly. | Lars, from your commit messages I see that you follow a different procedure | than I know from CVS times to update your branches. | I guess everybody knows how to create a branch: | | svn copy svn+ssh://svn.lyx.org/lyx/lyx-devel/trunk | svn+ssh://svn.lyx.org/lyx/lyx-devel/branches/mybranch | | but what is the preferred method to rebase it with trunk? The svn book is | not very helpful here. It would be very nice if you could explain it with a | few sentences. This could then be put in the wiki. I use a tree step process for rebasing. Initial branch creation: - svn cp Change/modify the branch as I see fit. Rebase -- (0. store the last and first rev on the branch, I get that from svn log --stop-on-copy) 1. svn delete -m 'rebase - step 1/3' 2. svn cp -m 'rebase - step 2/3' 3. a) checkout or switch to the branch, make sure it is up to date (equal to trunk) b) svn merge @firstrev @lastref c) verify that nothign bad has happened, fix conflicts etc. d) svn commit -m 'rebase - step 3/3' Creating the branch from a pristine copy of trunk is important to have this procedure work. -- Lgb
Re: [PATCH] CT cleanup - 3rd round
Martin Vermeer <[EMAIL PROTECTED]> writes: | On Tue, 2006-05-09 at 00:07 +0200, Michael Gerz wrote: | > Folks, | > | > this is the next part of the CT cleanup. | > | > I must confess that this patch will break CT in some cases (but not | > compilation, of course!). However, as I redesign the internal data | > structures (change tracking is no longer an "add-on" but an integral | > part of any paragraph and inset) it was impossible for me to find | > another self-contained set of changes that can be applied without | > breaking anything. I think we have to live with a broken CT for a week | > or two now (depending on how fast you accept my incremental changes). | > | > Please have a look at the patch and tell me whether it is OK. Its | > overall objective is to make things simpler and clearer. | | Precisely what breaks? | | I have no time right now to spend on LyX, but I think this should be | fixed before checking in. Or perhaps this is the time to give 'feature | branch' a try. Right. The patch itself looked ok to me. I liked the removal of some of the markErased functions etc. But I am wary of inconsistent trunk, we should work realy hard to have that not happen. -- Lgb
Re: Debut of the scons-based build system for lyx
Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> You should have said something then. Because without Abdelrazak> anyone saying anything it's difficult to get an idea. 3 Abdelrazak> saying yes and 0 saying no... I think you get the picture. Say what? "please do not commit before showing the patch?" Do I have to say that explicitely on each and every feature I think someone may come up with some day? I am repeating my self but it's a feature that touch _nothing_ at the current tree. So I reckon it is special. Bo have apologized already for this, could we please move on? What would have been wrong with committing in a branch, seriously? Convenience... The fact that these decisions are made only in terms of personal convenience makes it more difficult for scons to prove its personal merits. It is a pity. Convenience is a driving factor for me when I develop. Abdel.
AW: Re: [PATCH] CT cleanup - 3rd round
>John Levon <[EMAIL PROTECTED]> writes: > >| 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? > >I have no idea... it seems all my suggestions on using branches is put >down without even trying. Pardon. I DO know how branches work. I am not ignorant of this feature. I use it regularly at work. Abdel asked me to send small patches regularly rather than one big patch. However, if you change internal data structures, it is impossible to proceed without breaking things in the middle of the migration process. If you like to, I can open a new branch this evening, commit my complete patch, and half an hour later I will state that the mission is accomplished! Is this the purpose of a branch? Does this help you to understand my changes? I guess no... Please let me know how to continue. I don't want to waste too much time on administration and I don't want to waste your time as well. Michael
Re: Debut of the scons-based build system for lyx
Abdelrazak Younes <[EMAIL PROTECTED]> writes: | Georg Baum a écrit : | > Joost Verburg wrote: | > | >> If compilation with MSVC++ worked, the vcproj files would be very | >> useful. However, there are still incompatibilities that break important | >> things. | > Note that compilation with MSVC++ worked fine some months ago | > (version 2003 | > aka 7, not 6, that one is simply broken), and that the project files | > (although now outdated) are available in development/Win32. | | The problem with the vcproj file is the config.h guessing. This is | simply not possible. I've read that scons is able now to generate | these files so I would advocate to remove this vcproj file from SVN | when/if Scons prove itself and stays in SVN. but scons currently doesn this on every build (ok, only first time is really slow... further builds configure is just somewhat slow), is it avoidable? If nothing happens with scons in the next couple of days, I am going to remove it from trunk. And the onus is not on auto* people, but on proponents of scons, you have to show at the lest the begnnings of it being able to do what auto* is doing for us. -- Lgb
Re: AW: Re: [PATCH] CT cleanup - 3rd round
[EMAIL PROTECTED] writes: | >John Levon <[EMAIL PROTECTED]> writes: | > | >| 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? | > | >I have no idea... it seems all my suggestions on using branches is put | >down without even trying. | | Pardon. I DO know how branches work. I am not ignorant of this | feature. I use it regularly at work. | | Abdel asked me to send small patches regularly rather than one big | patch. However, if you change internal data structures, it is | impossible to proceed without breaking things in the middle of the | migration process. This is where we disagree. | If you like to, I can open a new branch this evening, commit my | complete patch, and half an hour later I will state that the mission | is accomplished! | Is this the purpose of a branch? Does this help you to understand my | changes? I guess no... You are still allowed ot send patches, one by one in small chunks showing us what you are going to do. You don't have to commit them one by one though. -- Lgb
Re: [Fwd: Re: Debut of the scons-based build system for lyx]
Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> John Levon a écrit : On Mon, May 08, 2006 at 04:19:29PM +0200, Abdelrazak Younes wrote: scons: Configure: Checking for main() in C library nsl... What is this nsl library? It's networking functions on certain UNIX types like Solaris. Abdelrazak> Thanks for the info, it is used in LyX client I suppose? Also in server... I spend some time getting this right for solaris, please do not ruin it. The objective is not to ruin anything but to complete scons support. And the X server needs it too, but I guess scons has some code of its own to handle that. Thanks for the info. Abdel.
Re: Debut of the scons-based build system for lyx
> "Abdel" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdel> I am repeating my self but it's a feature that touch Abdel> _nothing_ at the current tree. So I reckon it is special. We'll see. Abdel> Bo have apologized already for this, could we please move Abdel> on? It is not fair, I was away for the week-end and did not have the occasion to vent my frustration! JMarc
Re: AW: Re: [PATCH] CT cleanup - 3rd round
[EMAIL PROTECTED] a écrit : John Levon <[EMAIL PROTECTED]> writes: | 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? I have no idea... it seems all my suggestions on using branches is put down without even trying. Pardon. I DO know how branches work. I am not ignorant of this feature. I use it regularly at work. Abdel asked me to send small patches regularly rather than one big patch. Just for the record, I _suggested_ you to do that in order to ease reviewer process. I am not asking anything here :-) Abdel.
Re: [Fwd: Re: Debut of the scons-based build system for lyx]
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> The objective is not to ruin anything but to complete Abdelrazak> scons support. It is your parallel quest to eradicate config.h that makes me nervous :) JMarc
Re: Comparison between scons and autotools.
"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 Linux workstation, I get | | scons --config=force -j3 frontend=qt4 qt_dir=/path/to/qt4 => 6:37s | autogen.sh; ./configure; make -j3 | => 10:32s scons: 9m47.261s (null-build: 0m24.394s) auto: 13m11.433s (null-build: 0m7.952s) -- Lgb
Re: Re: [PATCH] CT cleanup - 3rd round
On Tue, May 09, 2006 at 11:41:10AM +0200, [EMAIL PROTECTED] wrote: > Abdel asked me to send small patches regularly rather than one big > patch. However, if you change internal data structures, it is > impossible to proceed without breaking things in the middle of the > migration process. 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 called away with work for a fortnight? Mini-branches are cheap and easy. Create one, make changes, create a patch, send the patch for review, repeat. A branch does not have to last for long. If we'd switched to Mercurial instead you'd be using a branch already! > Is this the purpose of a branch? Does this help you to understand my changes? > I guess no... See above. regards, john
Re: Re: [PATCH] CT cleanup - 3rd round
On Tue, May 09, 2006 at 12:01:22PM +0100, 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 > called away with work for a fortnight? BTW, the completely brokenness of the 1.4cvs trunk was a major factor in me pretty much giving up on LyX development. That and me being a git, of course. I don't know if you care, but I'm sure somebody does ;) regards john
Re: Debut of the scons-based build system for lyx
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 but they are called moc_ModuleName.cc instead of ModuleName_moc.C as I was used with the auto tools. I hope this is accounted for. Then I also see that it is also trying to compile uic_ModuleName.cc and this is completely new to me... They are generated and handled by scons automatically so you should not have to worry about them. I don't think so. Everything goes smooth until the final link step which miserably fails with tons of undefined references. These are partly due to the ordering of libraries in the link command (-lz should go after -lboost_*), partly due to some missing libraries (-lstdc++ -lcygwin -laspell), but the vast majority is a problem with that "undefined reference to `vtable for ...'" thing. I managed to achieve the final linking by hand so I think it's only that, nothing major. Abdel.
Re: Debut of the scons-based build system for lyx
Jean-Marc Lasgouttes a écrit : "Abdel" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdel> I am repeating my self but it's a feature that touch Abdel> _nothing_ at the current tree. So I reckon it is special. We'll see. Abdel> Bo have apologized already for this, could we please move Abdel> on? It is not fair, I was away for the week-end and did not have the occasion to vent my frustration! 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 :-) Abdel.
Re: [PATCH] CT cleanup - 3rd round
John Levon a écrit : On Tue, May 09, 2006 at 12:01:22PM +0100, 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 called away with work for a fortnight? BTW, the completely brokenness of the 1.4cvs trunk was a major factor in me pretty much giving up on LyX development. That and me being a git, of course. git like the new SCM tool from Linus Torvalds? I don't know if you care, but I'm sure somebody does ;) I do, and I was hoping that someday you will join me in qt4 development. Abdel.
Re: [Fwd: Re: Debut of the scons-based build system for lyx]
Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> The objective is not to ruin anything but to complete Abdelrazak> scons support. It is your parallel quest to eradicate config.h that makes me nervous :) N, not again this! ;-) More seriously, I have already agreed many times that it was not a good idea. Abdel.
Re: Getting rid of qttableview.[Ch]
Hum this mail is not in gmane too... Quoting Jean-Marc Lasgouttes <[EMAIL PROTECTED]>: > > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > Abdelrazak> Nothing happened to qttableview.h only to qttableview.C. > Abdelrazak> qttableview.h is the verbatim copy of december 2001; so > Abdelrazak> this is not a move of config.h to qttableview.C but a > Abdelrazak> creation. > > Indeed. And I have checked that both qt and boost input > without any guard, which means that we can indeed remove the > HAVE_LIMITS_H macro. Houra!!! We spoke about that bloody change for a complete day. > I am not sure it will change anything, though. This one in particular not much indeed. But it's one less configure test that consumes times. Abdel.
Re: Moving gettex.[Ch] and messages.[Ch] to src/support/
Quoting Jean-Marc Lasgouttes <[EMAIL PROTECTED]>: > > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > Abdelrazak> I guess that would be a "no" from JMarc and Lars so let's > Abdelrazak> just forget about this thread. Sorry for the noise. > > Hey! You did not give me a chance to say "no" by myself! > > So, as far as you original plan is concerned, my answer is indeed "no" > :) That's clear enough :-) > What I propose, though, is that you look at the convenience functions > defined in support/lyxlib.h and see which ones can be replaced by > boost thing. We probably do not need to implement mkdir, for example. > > One way of lessening the portability problem is to delegate it to > boost. Year there is a lot we can do there; but the major burden is actually gettext support. Unless we clean that or separate that from the rest, the configure step will remain slow. Abdel.
Re: Debut of the scons-based build system for lyx
Lars Gullik Bjønnes a écrit : Abdelrazak Younes <[EMAIL PROTECTED]> writes: | Georg Baum a écrit : | > Joost Verburg wrote: | > | >> If compilation with MSVC++ worked, the vcproj files would be very | >> useful. However, there are still incompatibilities that break important | >> things. | > Note that compilation with MSVC++ worked fine some months ago | > (version 2003 | > aka 7, not 6, that one is simply broken), and that the project files | > (although now outdated) are available in development/Win32. | | The problem with the vcproj file is the config.h guessing. This is | simply not possible. I've read that scons is able now to generate | these files so I would advocate to remove this vcproj file from SVN | when/if Scons prove itself and stays in SVN. but scons currently doesn this on every build (ok, only first time is really slow... further builds configure is just somewhat slow), is it avoidable? If nothing happens with scons in the next couple of days, I am going to remove it from trunk. And the onus is not on auto* people, but on proponents of scons, you have to show at the lest the begnnings of it being able to do what auto* is doing for us. Could I suggest that you list the initial features that you want so that scons stays in SVN? This will help us defining the priorities. It seems to me that scons is already capable of building a linux executable albeit without client support. Am I right here Bo? On windows/mingw, I reckon it is not far from completion except for Aspell support and NLS. Abdel.
Re: Fix --without-included-boost?
Quoting Jean-Marc Lasgouttes <[EMAIL PROTECTED]>: > > "younes" == younes a <[EMAIL PROTECTED]> writes: > > younes> I didn't know about that feature indeed but doing the autogen > younes> and configure steps each time you make a change to Makefile.am > younes> is a curse on windows. > > If you do a change to Makefile.am, the only thing that is going to > happen is that automake will rebuild the corresponding Makeilfe.in. > Are you seeing something different? Maybe I am getting it wrong but then you need to configure again so that Makefile is generated upon Makefile.in, don't you? Autogen is slow already but configure is slow as hell. I don't have precise number but when I do this reconfiguring because of a Makefile.am change, maybe 8 times out of 10, config.h is regenerated. Abdel.
Re: Getting rid of qttableview.[Ch]
> "younes" == younes a <[EMAIL PROTECTED]> writes: >> Indeed. And I have checked that both qt and boost input without >> any guard, which means that we can indeed remove the HAVE_LIMITS_H >> macro. younes> Houra!!! We spoke about that bloody change for a complete day. You would have been more convincing if you did the research yourself. For the future, I think that what boost does can be considered as a good guideline. What about getting rid of the stuff in support/lyxdir.h in favour of boost stuff. I am not sure everything can go away, but it seems there is room for cleanup. Careful cleanup, of course :) JMarc
Re: Fix --without-included-boost?
> "younes" == younes a <[EMAIL PROTECTED]> writes: younes> Maybe I am getting it wrong but then you need to configure younes> again so that Makefile is generated upon Makefile.in, don't younes> you? Autogen is slow already but configure is slow as hell. No, it is done automatically provided you did not use --disable-maintainer-mode. The case where is does not work is when modifying a m4 file in config/. In this case, you need to run ./autogen.sh (which runs autoconf and automake), and a configure run is needed. younes> I don't have precise number but when I do this reconfiguring younes> because of a Makefile.am change, maybe 8 times out of 10, younes> config.h is regenerated. It would be very useful if you could catch on of those instances. There is absolutely _no_ reason that modifying a Makefile.am can change config.h (besides a bug of course :) JMarc
Re: Getting rid of qttableview.[Ch]
Jean-Marc Lasgouttes a écrit : "younes" == younes a <[EMAIL PROTECTED]> writes: Indeed. And I have checked that both qt and boost input without any guard, which means that we can indeed remove the HAVE_LIMITS_H macro. younes> Houra!!! We spoke about that bloody change for a complete day. You would have been more convincing if you did the research yourself. I think (not sure) I have said that the original file didn't do the test and that Qt is very portable so why should we? For the future, I think that what boost does can be considered as a good guideline. What about getting rid of the stuff in support/lyxdir.h in favour of boost stuff. I am not sure everything can go away, but it seems there is room for cleanup. Hey, that's my point since the beginning ;-) Careful cleanup, of course :) Sure boss. I'll try to do something next week-end. But I will not touch autotools stuff. Abdel.
Re: Getting rid of qttableview.[Ch]
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "younes" == younes a <[EMAIL PROTECTED]> writes: | | >> Indeed. And I have checked that both qt and boost input without | >> any guard, which means that we can indeed remove the HAVE_LIMITS_H | >> macro. | | younes> Houra!!! We spoke about that bloody change for a complete day. | | You would have been more convincing if you did the research yourself. | For the future, I think that what boost does can be considered as a | good guideline. | | What about getting rid of the stuff in support/lyxdir.h in favour of | boost stuff. I am not sure everything can go away, but it seems there | is room for cleanup. support/lyxdir.h? -- Lgb
Re: Getting rid of qttableview.[Ch]
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> I think (not sure) I have said that the original file Abdelrazak> didn't do the test and that Qt is very portable so why Abdelrazak> should we? Yes, but the file was not part of qt itself, and I was suspicious it might not be as portable as the rest. My fault, I admit. >> For the future, I think that what boost does can be considered as a >> good guideline. What about getting rid of the stuff in >> support/lyxdir.h in favour of boost stuff. I am not sure everything >> can go away, but it seems there is room for cleanup. Abdelrazak> Hey, that's my point since the beginning ;-) So, why don't you do that first? mkdir should be too difficult to get right, for a start :) JMarc
Re: Fix --without-included-boost?
Jean-Marc Lasgouttes a écrit : "younes" == younes a <[EMAIL PROTECTED]> writes: younes> Maybe I am getting it wrong but then you need to configure younes> again so that Makefile is generated upon Makefile.in, don't younes> you? Autogen is slow already but configure is slow as hell. No, it is done automatically provided you did not use --disable-maintainer-mode. HA! I always use "--disable-maintainer-mode", it was recommended by Angus' and Michael' recipes for windows... :-( The case where is does not work is when modifying a m4 file in config/. In this case, you need to run ./autogen.sh (which runs autoconf and automake), and a configure run is needed. younes> I don't have precise number but when I do this reconfiguring younes> because of a Makefile.am change, maybe 8 times out of 10, younes> config.h is regenerated. It would be very useful if you could catch on of those instances. There is absolutely _no_ reason that modifying a Makefile.am can change config.h (besides a bug of course :) Scons is already much quicker than autotools so I think I will stick to it for now, even if it get removed from SVN. But sure I will test from time to time autotools compilation and report about that. Maybe this was all due to this "--disable-maintainer-mode" setting. Will see, thanks, Abdel. JMarc
Re: Getting rid of qttableview.[Ch]
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: | | Abdelrazak> I think (not sure) I have said that the original file | Abdelrazak> didn't do the test and that Qt is very portable so why | Abdelrazak> should we? | | Yes, but the file was not part of qt itself, and I was suspicious it | might not be as portable as the rest. My fault, I admit. | | >> For the future, I think that what boost does can be considered as a | >> good guideline. What about getting rid of the stuff in | >> support/lyxdir.h in favour of boost stuff. I am not sure everything | >> can go away, but it seems there is room for cleanup. | | Abdelrazak> Hey, that's my point since the beginning ;-) | | So, why don't you do that first? mkdir should be too difficult to get | right, for a start :) Actually that one is troublesome... last time I checked boost have no way of setting the mode for the created dir. And... the easy way to change these functions is not to change the header files, at least not initally, but just change the implementation. And if possible add a test to support/tests -- Lgb
Re: Fix --without-included-boost?
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Scons is already much quicker than autotools so I think I Abdelrazak> will stick to it for now, even if it get removed from SVN. Abdelrazak> But sure I will test from time to time autotools Abdelrazak> compilation and report about that. Maybe this was all due Abdelrazak> to this "--disable-maintainer-mode" setting. It would be nice to know. JMarc
Re: Getting rid of qttableview.[Ch]
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> support/lyxdir.h? Sorry. support/lyxlib.h. I think most of it is covered by boost, isn't it? JMarc
Re: Getting rid of qttableview.[Ch]
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Actually that one is troublesome... last time I checked boost Lars> have no way of setting the mode for the created dir. What mode does it use? I see we use either 700 or 777, why is that? We could just rely on umask, couldn't we? I remember a discussion on this subject, but not the outcome. Lars> And... the easy way to change these functions is not to change Lars> the header files, at least not initally, but just change the Lars> implementation. Or not use the function at all, but rather boost directly? JMarc
Re: Getting rid of qttableview.[Ch]
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Actually that one is troublesome... last time I checked boost Lars> have no way of setting the mode for the created dir. Jean-Marc> What mode does it use? I see we use either 700 or 777, why Jean-Marc> is that? Answering to myself: I see boost only uses 777. We need 700 to avoid making our temp files readable/writeable to other users. JMarc
Re: Getting rid of qttableview.[Ch]
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> support/lyxdir.h? | | Sorry. support/lyxlib.h. I think most of it is covered by boost, isn't | it? getcwd rename¹ copy unlink mkdir² ¹ boost::rename might not be good enough, our falls back to copy if the files reside on different filesystems. ² boost::mkdir does not take a mode argument, and thus is not really usable for us. -- Lgb
Re: Getting rid of qttableview.[Ch]
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> And... the easy way to change these functions is not to change | Lars> the header files, at least not initally, but just change the | Lars> implementation. | | Or not use the function at all, but rather boost directly? I would prefere just the implementation initially, then it is clearly localized, and you change all callers at once. -- Lgb
Scons: almost there
Dear all, If nothing happens with scons in the next couple of days, I am going to remove it from trunk. Since when have you become so time-conscious? May I ask again ? We are getting closer, I think. I still have to find time to make up my mind about non/auto/"". Patience ;) 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 2. scons in a native cygwin, cygwin/qt3, cygwin/boost, cygwin/zlib etc. For the last case, however, although native cygwin libz is present, the linker asks for official zlib1.dll. Enrico, could you please investigate this issue? To link successfully, you will need to get the last command (copy/paste from screeen or scons_lyx.log), add /path/to/zlib1.dll to the end, and build again. I notice that linking under cygwin/qt3 is much quicker than mingw/qt3. With some tweak regarding spell checkers and a few other libraries (maybe also pch), and some scons install capacity, this will be a totally usable. I hope this will earn scons a place in the trunk. BTW, much of my time has been wasted on the .C/.c madness under windows. Although scons has overcomed this problem, can we make a quick decision regarding the name change? After all, it is only "find ... svn rename grep .. Makefile.am... perl -pi.bak" away. If you are worrying about backporting, let us do it on 1.4.x as well. Cheers, Bo
Re: Scons: almost there
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes: Bo> Dear all, >> If nothing happens with scons in the next couple of days, I am >> going to remove it from trunk. Bo> Since when have you become so time-conscious? May I ask again Bo> ? Bo> We are getting closer, I think. I still have Bo> to find time to make up my mind about non/auto/"". Bo> Patience ;) First quote was Lars. Second one is me. Bo> BTW, much of my time has been wasted on the .C/.c madness under Bo> windows. Although scons has overcomed this problem, can we make a Bo> quick decision regarding the name change? After all, it is only Bo> "find ... svn rename grep .. Makefile.am... perl -pi.bak" Bo> away. Is the problem fixed or not? Bo> If you are worrying about backporting, let us do it on 1.4.x as Bo> well. Please no renaming in 1.4.x. JMarc
Re: Scons: almost there
Bo Peng wrote: > BTW, much of my time has been wasted on the .C/.c madness under > windows. Although scons has overcomed this problem, can we make a > quick decision regarding the name change? After all, it is only "find > ... svn rename grep .. Makefile.am... perl -pi.bak" away. If you > are worrying about backporting, let us do it on 1.4.x as well. I thought that initially, too, but there is a good reason for not doing it: Providing a patch from 1.4.1 to 1.4.2 would not make sense anymore. Georg
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 directly under linux + lyx qt3/qt4 ... (state of yesterday) | 1. scons directly using mingw + lyx qt3/4 + official zlib1.dll in a | visible place | 2. scons in a native cygwin, cygwin/qt3, cygwin/boost, cygwin/zlib etc. 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. I see no or littel support for these in scons, so _you_ have to show that it can be done. (and not that that compiler args vary between compiler versions, not just between compiler brands) | With some tweak regarding spell checkers and a few other libraries | (maybe also pch), and some scons install capacity, this will be a | totally usable. I hope this will earn scons a place in the trunk. Totally usable is not good enough. It must handle the same problems as autotools does. I am not saying that this must be done promtly, but at least it must be shown that it can be done. (and without creating something that is just as complex as auto*) | BTW, much of my time has been wasted on the .C/.c madness under | windows. You mean "The Windows madness"... -- Lgb
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 by one basis. The advantage of scons is that (almost) anyone can read SConstruct and add the feature he wants. I *will not* add every single feature that autotools have now. I see no or littel support for these in scons, so _you_ have to show that it can be done. (and not that that compiler args vary between compiler versions, not just between compiler brands) No. I have no intention, as of now, to replace autotools with scons. All I need is a quicker and more flexible method to build lyx for my own lyx coding. I have shown some advantages of scons over autotools under linux, and Abdel will surely show you more gains under windows. That is currently enough for us. Totally usable is not good enough. It must handle the same problems as autotools does. I am not saying that this must be done promtly, but at least it must be shown that it can be done. (and without creating something that is just as complex as auto*) Doing all these "scons dist" stuff, as I have said before, is possible. There are code everywhere (even at the end of scons_utils.py) but since scons is standardizing these features. It is much wiser to wait. | BTW, much of my time has been wasted on the .C/.c madness under | windows. You mean "The Windows madness"... You may rightly say so. Bo
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 but they are
> >>>called moc_ModuleName.cc instead of ModuleName_moc.C as I was used
> >>>with the auto tools. I hope this is accounted for.
> >>>Then I also see that it is also trying to compile uic_ModuleName.cc
> >>>and this is completely new to me...
> >>They are generated and handled by scons automatically so you should
> >>not have to worry about them.
> >
> >I don't think so. Everything goes smooth until the final link step
> >which miserably fails with tons of undefined references.
> >
> >These are partly due to the ordering of libraries in the link command
> >(-lz should go after -lboost_*), partly due to some missing
> >libraries (-lstdc++ -lcygwin -laspell), but the vast majority is
> >a problem with that "undefined reference to `vtable for ...'" thing.
>
> I managed to achieve the final linking by hand so I think it's only
> that, nothing major.
Are you saying that .C files are recognized as C++ sources for you?
Then, I am sorry, but SCons has wrong support for cygwin. For example,
I see the following in site-packages/SCons/Util.py:
if sys.platform == 'cygwin':
# On Cygwin, os.path.normcase() lies, so just report back the
# fact that the underlying Windows OS is case-insensitive.
def case_sensitive_suffixes(s1, s2):
return 0
else:
def case_sensitive_suffixes(s1, s2):
return (os.path.normcase(s1) != os.path.normcase(s2))
and also this one in site-packages/SCons/FS.py:
# Cygwin's os.path.normcase pretends it's on a case-sensitive filesystem.
_is_cygwin = sys.platform == "cygwin"
if os.path.normcase("TeSt") == os.path.normpath("TeSt") and not _is_cygwin:
def _my_normcase(x):
return x
else:
def _my_normcase(x):
return string.upper(x)
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.
--
Enrico
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 that the .rdata problem is now correctly handled (hidden in SConstruct), which is, in my opinion, the most troublesome thing for a cygwin/lyx build. Now, from my machine, with the right cygwin packages (and your moc.exe and uic.exe), cygwin/lyx is almost a direct scons away. Bo
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 "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/". Abdel.
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 vtable" solved? > Please, if you can, help me > figure out why cygwin build lyx needs zlib1.dll, instead of cygwin > libz.a. I will gladly do that but I don't I understand what you mean. On cygwin you should use -lz and by default it should link using /usr/lib/libz.dll.a, which is the import library for /usr/bin/cygz.dll. There is also a static /usr/lib/libz.a, but it should not be used unless you provide the -static option. I think I'll figure out that one by myself trying scons again. > It seems that the .rdata problem is now correctly handled (hidden in > SConstruct), which is, in my opinion, the most troublesome thing for a > cygwin/lyx build. I saw you clever solution, but the rdata script is only needed when linking against the X11 libs. I don't think that it may be harmful, though, but it can be done in this simple way: if X11 is requested then use the script else add -DQ_CYGWIN_WIN to CPPFLAGS. This brings me to the question of how passing options. I tried adding CPPFLAGS=-O2 on the scons command line but it doesn't seem to have worked. > Now, from my machine, with the right cygwin packages (and your moc.exe > and uic.exe), cygwin/lyx is almost a direct scons away. I'll try and report the results. However, be warned that I almost never accept defaults and try to push a software to do what I want and not what it thinks is the best for me ;-) -- Enrico
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. Can I leave this to you as a Python exercise? It is time for you to read the Python tutorial (You do not even need that for this change.) BTW, have you tried the updated system? If possible, you can record the compiling time and post to the comparison thread. Bo
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 manually moc the necessary files. > Please, if you can, help me > figure out why cygwin build lyx needs zlib1.dll, instead of cygwin > libz.a. I will gladly do that but I don't I understand what you mean. On cygwin you should use -lz and by default it should link using /usr/lib/libz.dll.a, which is the import library for /usr/bin/cygz.dll. There is also a static /usr/lib/libz.a, but it should not be used unless you provide the -static option. That is also my understanding, but on my system, the link failed with unknown references to zlib stuff. I then tried to feed it zlib1.dll from www.zlib.org, and ld succeeded. > It seems that the .rdata problem is now correctly handled (hidden in > SConstruct), which is, in my opinion, the most troublesome thing for a > cygwin/lyx build. I saw you clever solution, but the rdata script is only needed when linking against the X11 libs. Right now, I assume that a cygwin build will use cygwin qt3 (a right choice) so the script is used. If you would like to use standalone qt3/qt4, you may have to pass a flag that change things like default system libraries. I don't think that it may be harmful, though, but it can be done in this simple way: if X11 is requested then use the script else add -DQ_CYGWIN_WIN to CPPFLAGS. This can be done easily. This brings me to the question of how passing options. I tried adding CPPFLAGS=-O2 on the scons command line but it doesn't seem to have worked. This is supposed to work if I add "xxx', which means something easy but not known by me, given my one week experience with scons. I'll try and report the results. However, be warned that I almost never accept defaults and try to push a software to do what I want and not what it thinks is the best for me ;-) I know. There are lots of FIXMEs regarding such things, and you are more than welcome to tweak things for your own convenience and optimization, *after* the basis is figured out. Cheers, Bo
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 > 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. 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 that autotools have Bo> now. But you will eventually? The idea of reimplementing the m4 code I wrote in python because you prefer python to autoconf does not appeal to me a lot. Bo> No. I have no intention, as of now, to replace autotools with Bo> scons. All I need is a quicker and more flexible method to build Bo> lyx for my own lyx coding. I have shown some advantages of scons Bo> over autotools under linux, and Abdel will surely show you more Bo> gains under windows. That is currently enough for us. Is there hope to avoid requiring installing SCons before compiling LyX from tar.gz? The python requirement itself is pretty much OK, since we use it elsewhere. JMarc
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 right here Bo? And many --enable--xxx options, which I am not sure if they are actually used (or useful). On windows/mingw, I reckon it is not far from completion except for Aspell support and NLS. Yeah, I can finally ignore the configure script. Bo
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 compile it, but LyX itself will have bugs due to undefined behavior of certain functions. For example, the MinGW implementations of functions to call other applications often do not show a console window, while the Microsoft implementation does. This means that you get popping up windows all the time. Joost
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 for
Joost> some time while working on the new Windows installer, it works
Joost> fine.
So the patch would be basically getting rid of config/cygwin.m4, right?
The code this is in cygwin.m4 in trunk should go the qt{,4}.m4, I
think.
JMarc
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 === --- config/cygwin.m4(revision 13592) +++ config/cygwin.m4(working copy) @@ -7,16 +7,6 @@ cygwin* | mingw* | pw32* ) # Export all symbols to Win32 DLL using MinGW 2.0 ld. WIN32_LD_EXPORT_ALL_SYMBOLS='' -AC_MSG_CHECKING([whether ld accepts --export-all-symbols]) -if $LD --help 2>&1 | egrep 'export-all-symbols' > /dev/null; then - WIN32_LD_EXPORT_ALL_SYMBOLS='-Wl,--export-all-symbols' - AC_MSG_RESULT([yes]) -else - AC_MSG_RESULT([no]) -fi -if test x"$WIN32_LD_EXPORT_ALL_SYMBOLS" != x; then - LDFLAGS="$LDFLAGS $WIN32_LD_EXPORT_ALL_SYMBOLS" -fi ;; esac ])
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 that autotools have Bo> now. But you will eventually? I do not know. If something comes out as a request, I (or someone else) will add it. If it does not show up till the end, that means this feature is not needed. The idea of reimplementing the m4 code I wrote in python because you prefer python to autoconf does not appeal to me a lot. I know. scons lacks of a huge library of such things. I actually copied the SELECT_ARG thing from the autoconf source code. However, if something is not readily available, it will be much easier for me to implement in Python. I guess you can read scons_utils.py and make your judgement. (BTW, we do need to copy various autoconf macros to the config directory, and those macros are usually longer (and more obscure) than their python counterparts.) Bo> No. I have no intention, as of now, to replace autotools with Bo> scons. All I need is a quicker and more flexible method to build Bo> lyx for my own lyx coding. I have shown some advantages of scons Bo> over autotools under linux, and Abdel will surely show you more Bo> gains under windows. That is currently enough for us. Is there hope to avoid requiring installing SCons before compiling LyX from tar.gz? The python requirement itself is pretty much OK, since we use it elsewhere. Such a thing exists. It is called scons-local, readily downloadable with scons source. If some procedure requires ./configure. make, make install, we can fake them. Bo
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. JMarc
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 reading the configuration file lyxrc.defaults. Michael> Please check your installation. Michael> Removing ~/.lyx-1.4.2svn didn't help. Does anybody have the Michael> same problem? Bennett> I had similar problem on Mac. This patch fixes it, with one Bennett> glitch. Bennett> When LyX-1.4.2svn is run the first time, it reads in Bennett> lyxrc.dist, then finds that there is no lyxrc.defaults and so Bennett> runs reconfigure. But lyxrc.defaults is never read after it Bennett> is generated. Michael, Bennett, could you confirm that these problems are solved now? JMarc
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 files because it > is .c under windows. I have corrected the problem by manually moc the > necessary files. Hmmm... This risks to be error prone. SCons should be fixed to recognize .C files as source files also on Windows. > > > >> Please, if you can, help me > >> figure out why cygwin build lyx needs zlib1.dll, instead of cygwin > >> libz.a. > > > >I will gladly do that but I don't I understand what you mean. > >On cygwin you should use -lz and by default it should link using > >/usr/lib/libz.dll.a, which is the import library for /usr/bin/cygz.dll. > >There is also a static /usr/lib/libz.a, but it should not be used unless > >you provide the -static option. > > That is also my understanding, but on my system, the link failed with > unknown references to zlib stuff. I then tried to feed it zlib1.dll > from www.zlib.org, and ld succeeded. Yesterday, when I tried scons for the first time, I also noticed that. The problem was simply that -lz is specified on the final link step before the -lboost_* libraries. Moving -lz at the end solved the problem. > >> It seems that the .rdata problem is now correctly handled (hidden in > >> SConstruct), which is, in my opinion, the most troublesome thing for a > >> cygwin/lyx build. > > > >I saw you clever solution, but the rdata script is only needed when > >linking against the X11 libs. > > Right now, I assume that a cygwin build will use cygwin qt3 (a right > choice) so the script is used. If you would like to use standalone > qt3/qt4, you may have to pass a flag that change things like default > system libraries. How is that done with scons? > >I don't think that it may be harmful, though, but it can be done in > >this simple way: if X11 is requested then use the script else add > >-DQ_CYGWIN_WIN to CPPFLAGS. > > This can be done easily. I suggest a boolean "without_x11". > >This brings me to the question of how passing options. I tried adding > >CPPFLAGS=-O2 on the scons command line but it doesn't seem to have > >worked. > > This is supposed to work if I add "xxx', which means something easy > but not known by me, given my one week experience with scons. ;-) > >I'll try and report the results. However, be warned that I almost > >never accept defaults and try to push a software to do what I want > >and not what it thinks is the best for me ;-) > > I know. There are lots of FIXMEs regarding such things, and you are > more than welcome to tweak things for your own convenience and > optimization, *after* the basis is figured out. Yes, python should be easier to tweak than m4, but we have to prove that it can be as powerful as m4 is. I'll tell you that the first time I was faced with vi on Unix, I was really lost and don't even succeeded to quit it without peeking at a manual. I remember that I promised to never use vi because it was so unfriendly to the user. Today I would not use anything but vim for editing because it is so powerful. What I mean is that I will help to tune scons but I do not promise to leave autotools for it unless it proves to be at least as powerful as they already are. For example, the -lz thing is a con for scons (sorry for the pun), as libtool is able to handle the reordering of libraries quite well. -- Enrico
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 linking. That works > perfectly. I start thinking that scons is too much Windows centric... -- Enrico
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. _And_ Scons could search the > >required dll in "d:/mingw/bin/". > > Agreed. Can I leave this to you as a Python exercise? It is time for > you to read the Python tutorial (You do not even need that for this > change.) > > BTW, have you tried the updated system? If possible, you can record > the compiling time and post to the comparison thread. 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. -- Enrico
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" etc. I'll tell you that the first time I was faced with vi on Unix, I was really lost and don't even succeeded to quit it without peeking at a manual. I remember that I promised to never use vi because it was so unfriendly to the user. Today I would not use anything but vim for editing because it is so powerful. Vim is *the* editing tool for me. *You can tell from the first line of every SCons* files). What I mean is that I will help to tune scons but I do not promise to leave autotools for it unless it proves to be at least as powerful as they already are. 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). Bo
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 of Sconstruct and add things like ['O3']. (Not tested) Bo
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. Thanks. So the following (plus removal of cygwin.m4) would be just as good, right? JMarc Index: configure.ac === --- configure.ac (revision 13813) +++ configure.ac (working copy) @@ -144,9 +144,6 @@ #AM_PROG_LIBTOOL LYX_PROG_LIBTOOL -### Check for some Cygwin-specific details. -CHECK_WITH_CYGWIN - ### Check for X libraries AC_PATH_XTRA case $have_x in Index: config/Makefile.am === --- config/Makefile.am (revision 13813) +++ config/Makefile.am (working copy) @@ -2,7 +2,6 @@ EXTRA_DIST = \ common.am \ - cygwin.m4 \ gnome--.m4 \ gnome.m4 \ gtk--.m4 \
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 time. 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. JMarc
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 before compiling >> LyX from tar.gz? The python requirement itself is pretty much OK, >> since we use it elsewhere. Bo> Such a thing exists. It is called scons-local, readily Bo> downloadable with scons source. If some procedure requires Bo> ./configure. make, make install, we can fake them. I see it uses 200k when zipped, which is comparable to a configure script. So it is not too bad, but the global footprint will remain the same. JMarc
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; ./configure; make -j3 => 10:32s I expect larger difference under windows, but we need to wait for the numbers there. Windows/mingw/qt4 scons frontend=qt4 qt_dir=d:/program/Qt/4.1 extra_inc_path=d:/mingw/include extra_lib_path=d:/mingw/lib clean compile lyx+tex2lyx = 45 minutes null compile = 4 minutes Loading qt4 tool... 45 seconds scons: Building targets ... 3 minutes Windows/cygwin/mingw/qt4 autogen.sh 2 minutes configure 6 minutes I don't have the time to do a full autotools recompile now but IIRC it was around 1h30. A null compile is quicker though, we need to tweak that Bo because waiting 4 minutes for nothing is not acceptable. What's this "Loading qt4 tool" doing? Is it possible to just skip the first config phase? Abdel.
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? Joost> Here it is. Thanks. So the following (plus removal of cygwin.m4) would be just as good, right? No please just use the cygwin.m4 from trunk as I added an option for Enrico. Abdel.
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 build system should be able to be really faster than an automake-based one. BTW, with ccache, I can do 'make clean; make' in something like 13 minutes (on 1.4)... JMarc
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 undefined reference I got: Info: resolving __ZN2Qt11arrowCursrelease/cygwin-qt3-X11/libs/libcontrollers.a(ControlSpellchecker.o):ControlSpellchecker.C:(.text+0x6f1): undefined reference to `ASpell::ASpell(BufferParams const&, std::basic_string, std::allocator > const&)' orE by linking to __imp___ZN2Qt11arrowCursorE (auto-import) collect2: ld returned 1 exit status because I asked for aspell support when configuring (I presume that it is not possible to have aspell at the moment). BTW, how can I add "-O2" to the compiler flags? I tried CPPFLAGS=-O2 on the command line, and also "export CPPFLAGS=-O2", but scons seems to ignore both. -- Enrico
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 JMarc'c call. > > 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. > > So the patch would be basically getting rid of config/cygwin.m4, right? No, please. config/cygwin.m4 in 1.5 should be copied verbatim to 1.4. -- Enrico
Re: Comparison between scons and autotools.
Abdelrazak Younes a écrit : 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; ./configure; make -j3 => 10:32s I expect larger difference under windows, but we need to wait for the numbers there. Windows/mingw/qt4 scons frontend=qt4 qt_dir=d:/program/Qt/4.1 extra_inc_path=d:/mingw/include extra_lib_path=d:/mingw/lib clean compile lyx+tex2lyx =45 minutes null compile =4 minutes Loading qt4 tool... 45 seconds scons: Building targets ...3 minutes Windows/cygwin/mingw/qt4 autogen.sh2 minutes configure6 minutes Hum this was with cached tests. On a clean state, configure takes 12 minutes here. And, by the way, my machine is a pentium 4 mobile 1.8GHz and 768Mo RAM. I guess that now that you can compare your few minutes on linux with my few hours on windows you can understand that it is good to do something about that build system. Abdel.
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 since they rely on sh/sed etc. 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? -- Enrico
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", but scons seems to ignore both. Please see my previous email. Bo
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 following error Michael> message: Michael> Error while reading the configuration file lyxrc.defaults. Michael> Please check your installation. Michael> Removing ~/.lyx-1.4.2svn didn't help. Does anybody have the Michael> same problem? Bennett> I had similar problem on Mac. This patch fixes it, with one Bennett> glitch. Bennett> When LyX-1.4.2svn is run the first time, it reads in Bennett> lyxrc.dist, then finds that there is no lyxrc.defaults and so Bennett> runs reconfigure. But lyxrc.defaults is never read after it Bennett> is generated. Michael, Bennett, could you confirm that these problems are solved now? The glitch is now fixed as well. The only remaining problem for me is that lyxrc.defaults gets read after lyxrc.dist, overwriting settings that should be defaults on Mac. That's the auto-view stuff Bennett
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. Autotools' recursive-make approach only cares about current and sub directories, and is faster in this regard. (BTW, use scons -u to build only a subdirectory). 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. Using scons should reduce the chance of such a waste of time. Note that one can let scons check time stamp, this should reduce starting time a bit. 2. Currently, I use the default settings of scons (like copying files to build directory) to ganrantee correct build. I will try to change to non-copy if things go well. 3. Waf is a KDE variant of scons. It is a product of insufficient communication between KDE and scons developers. I personally hate such branched projects since they make users (us) difficult to choose (like emacs/xemacs) and may lead to wasted efforts (like klyx?) Waf aims to fix many concerns of scons, one of which is the starting time. I will give waf a try later. I will also ask the scons-user list for an opinion. Cheers, Bo
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 > > > >scons --config=force -j3 frontend=qt4 qt_dir=/path/to/qt4 => 6:37s > >autogen.sh; ./configure; make -j3 > > => 10:32s > > > >I expect larger difference under windows, but we need to wait for the > >numbers there. > > Windows/mingw/qt4 > > scons frontend=qt4 qt_dir=d:/program/Qt/4.1 > extra_inc_path=d:/mingw/include extra_lib_path=d:/mingw/lib > > clean compile lyx+tex2lyx = 45 minutes > > null compile =4 minutes > Loading qt4 tool... 45 seconds > scons: Building targets ... 3 minutes > > Windows/cygwin/mingw/qt4 > autogen.sh2 minutes > configure 6 minutes > > I don't have the time to do a full autotools recompile now but IIRC it > was around 1h30. A null compile is quicker though, we need to tweak that > Bo because waiting 4 minutes for nothing is not acceptable. What's this > "Loading qt4 tool" doing? Is it possible to just skip the first config > phase? 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. -- Enrico
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++. However, at linking time, gcc and g++ may lead to different results (stdc++.so etc). A renaming of lyx .C files will never happen so we will have to use the current solution, .i.e., force moc'ing, and force the use of g++ (I know, this leads to non-portability. but this is life). Bo
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 called away with work for a fortnight? BTW, the completely brokenness of the 1.4cvs trunk was a major factor in me pretty much giving up on LyX development. That and me being a git, of course. I don't know if you care, but I'm sure somebody does ;) OK, OK, OK,... you convinced me. Sending patches to the list but not being allowed to commit them is the worst alternative for me. 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. Michael
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 know. Almost. It seems I can't have aspell support. > Before I figure out how to pass -O3, you can edit line 707 of > Sconstruct and add things like ['O3']. (Not tested) I think I am fine with '-O2' ;-) 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). -- Enrico
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
