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 I have a patch at hand that works (at least it should be good enough
for the
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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
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
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]
|
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
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
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
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
[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*
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
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
[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
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
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
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
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
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
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?
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
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
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
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!
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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 ?
Quote, 5 days ago
We are getting closer, I think. I still have to find time to make up
my mind about non/auto/.
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 Quote, 5 days ago We are getting closer, I think. I still have
Bo to
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
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
Bo Peng [EMAIL PROTECTED] writes:
| Quote, 5 days ago
| We are getting closer, I think. I still have to find time to make up
| my mind about non/auto/.
|
| Patience ;)
| /Quote
And you clearly showed that you had no patience.
| I just submitted another patch. With it, one can
| 0. scons
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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;
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
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
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
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
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
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
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
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
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
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
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.
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
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++.
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
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.
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
1 - 100 of 292 matches
Mail list logo
