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 th
> "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 a
> "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
> "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 incompatibili
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 b
> "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
> "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
>>
>>
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 sug
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 >
| >> ... >
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
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 ce
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 sim
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 in
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
>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
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++ w
[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
| >| *kn
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 networkin
> "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 wa
[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 unde
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 b
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
Abde
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 be
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; s
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 t
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.
| > Not
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
> "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 mo
> "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 y
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.
Y
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 abou
> "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
migh
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 d
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
> "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
> "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
> "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
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 goo
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
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 su
> "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
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:
|
| 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 +
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 b
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
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
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
"extra_inc_path=d:/mingw/i
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 vta
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.
> 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 m
> "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 >
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 ri
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 f
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.
JMa
> "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 r
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 fi
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 lin
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
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" et
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
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
> "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
> "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 befo
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; ./configu
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?
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 bu
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 undefin
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 J
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 =
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
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 followin
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. Au
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
> >
> >sco
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,
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
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
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 146 matches
Mail list logo