Martin Vermeer wrote:
Yes, way more readable, less guesswork.
I wish I had time to check out your branch and try for myself... no
chance until next week.
The branch is broken anyway and it does not include all available
patches. The situation will be better next week.
Michael
Abdelrazak Younes wrote:
But that's my point, one should not have to recompile everything because
of a single setting change that impact the compilation of a single file.
If you know that it should only recompile a single file or two, then
just touch the object files first, and then touch the
Please, attached find a patch fixing compilation with aiksaurus
and some other small thing.
All look reasonable. Will be applied.
Please, have a look at version.C.in as there are a couple of strings
("@PACKAGE_VERSION@" and "@VERSION_INFO@") that are not substituted
when generating version.C.
On Tue, May 09, 2006 at 04:44:47PM -0500, Bo Peng wrote:
> Now, I think I can claim that scons is *basically* working. It is
> already a straight 'scons' for linux, mingw and cygwin.
And now solaris, too. I start liking this scons thing ;-)
Please, attached find a patch fixing compilation with a
On Wed, 2006-05-10 at 00:01 +0200, Michael Gerz wrote:
> Hi,
>
> just too many things happended implicitly in the CT code.
>
> Attached please find a rather boring cleanup for my personal CT branch.
Yes, way more readable, less guesswork.
I wish I had time to check out your branch and try for m
Michael Gerz <[EMAIL PROTECTED]> writes:
> > Since when is it allowed to compare an object with an enum???
> I found it out by myself: The enum is a constructor argument, i.e., it
> is converted into an object. Very ugly.
Sounds like you should add the explicit keyword to the constructor...
Ang
On Tue, May 09, 2006 at 04:44:47PM -0500, Bo Peng wrote:
> >Hmmm... I blindly applied my patch over your new commit without
> >reading it. Please, note the "appnend" typo.
>
> Yes. That is a ugly one. I will fix that one with others.
Ok, Thanks.
> Now, I think I can claim that scons is *basicall
On Tue, May 09, 2006 at 02:59:38PM -0500, Bo Peng wrote:
> spell checker and aikasurus are
> supposed to work now.
The spell checker works, but, although the Aiksaurus library is
indeed linked in, I am missing the Thesaurus entry in the Tools
menu.
Many things should still be tuned, among them:
On Wed, May 10, 2006 at 12:01:46AM +0200, Michael Gerz wrote:
> just too many things happended implicitly in the CT code.
Seems OK
john
Hi,
just too many things happended implicitly in the CT code.
Attached please find a rather boring cleanup for my personal CT branch.
Michael
Index: paragraph.h
===
--- paragraph.h (Revision 13819)
+++ paragraph.h (Arbeitskopie)
@@
Word from the master of waf: Thomas Nagy (Applause, please)
* Adding '#include "foo.moc"' at the end of 'foo.C'
will reduce compilation times by 30-40% on the
average. The old scheme will not be supported in Waf
and i believe scons now supports the foo.moc scheme
too.
## Bo: Does anydoby know t
On Mon, May 08, 2006 at 10:57:12AM -0500, Bo Peng wrote:
> >It should not be in svn beforee it at least can compile linux
> >trivially.
>
> And it will work trivially under windows soon, if more testing, as a
> result of more publicity is allowed. I guarantee you that it will
> achieve a state of
On Tue, May 09, 2006 at 11:06:58PM +0200, Michael Gerz wrote:
> >These should be disabled if there's nothing /to/ reject or accept. If
> >that's too hard or slow to do then OK, but we should try.
> >
> I will send you a screenshot tomorrow. Right now, my tree is broken.
> Actually, my plans are t
John Levon wrote:
No. The test has been removed on purpose. In fact, the major motivation
of the CT code changes is the user requirement to switch CT off without
having to accept all changes before.
I know. Read what I wrote :)
These should be disabled if there's nothing /to/ reject or a
Hmmm... I blindly applied my patch over your new commit without
reading it. Please, note the "appnend" typo.
Yes. That is a ugly one. I will fix that one with others.
Now, I think I can claim that scons is *basically* working. It is
already a straight 'scons' for linux, mingw and cygwin. The co
On Tue, May 09, 2006 at 10:52:27PM +0200, Michael Gerz wrote:
> >>case LFUN_CHANGE_REJECT: // what about these two
> >>case LFUN_ALL_CHANGES_ACCEPT:
> >>case LFUN_ALL_CHANGES_REJECT:
> >>- flag.enabled(buffer_ && buffer_->params().tracking_changes);
> >>+ flag.enabl
John Levon wrote:
On Tue, May 09, 2006 at 10:27:17PM +0200, Michael Gerz wrote:
case LFUN_CHANGE_REJECT: // what about these two
case LFUN_ALL_CHANGES_ACCEPT:
case LFUN_ALL_CHANGES_REJECT:
- flag.enabled(buffer_ && buffer_->params().tracking_changes);
+
On Tue, May 09, 2006 at 10:27:17PM +0200, Michael Gerz wrote:
> case LFUN_CHANGE_REJECT: // what about these two
> case LFUN_ALL_CHANGES_ACCEPT:
> case LFUN_ALL_CHANGES_REJECT:
> - flag.enabled(buffer_ && buffer_->params().tracking_changes);
> + flag.enabl
On Tue, May 09, 2006 at 10:57:29PM +0200, Enrico Forestieri wrote:
> I had just compiled successfully with aspell support when I saw your
> new commit. I still think that the attached patch is necessary.
Hmmm... I blindly applied my patch over your new commit without
reading it. Please, note the
Hello,
the following patch for my personal branch decouples the tracking of
changes from the output of changes, i.e., you can turn both on and off
at any time. The patch will also enable (once the LyX core is fixed)
accepting/rejecting changes even if ct is switched off.
I assume that techni
On Tue, May 09, 2006 at 09:19:17PM +0200, Andre Poenitz wrote:
> > > I must confess that this patch will break CT in some cases
> >
> > Why is there such pushback against making branches for stuff that's
> > *known* broken?
>
> Because maintaining branches is an extra effort that eats resources.
On Tue, May 09, 2006 at 10:00:51PM +0200, Andre Poenitz wrote:
> On Tue, May 09, 2006 at 12:04:44PM -0500, Bo Peng wrote:
> > I am too new to scons to give a full solution here. Here are some of
> > my opinions:
> >
> > 1. The check content (md5) approach is better than autotools since
> > time st
On Tue, May 09, 2006 at 02:59:38PM -0500, Bo Peng wrote:
> >And you compiled using -O2 with scons, too, right? Otherwise this is
> >an unfair comparison. I have numbers close to yours on cygwin, but I
> >cannot convince scons to compile using -O2.
>
> With scons CCFLAGS=-O2, the compile time are a
Michael Gerz wrote:
Hi folks,
could somebody please tell me why this piece of code compiles:
bool const show_change = par.lookupChange(cur.pos()) !=
Change::UNCHANGED;
as we have this
class Change {
public:
/// the type of change
enum Type {
UNCHA
Hi folks,
could somebody please tell me why this piece of code compiles:
bool const show_change = par.lookupChange(cur.pos()) !=
Change::UNCHANGED;
as we have this
class Change {
public:
/// the type of change
enum Type {
UNCHANGED, // no change
The second column is bad. Developers certainly spend more time
on near 'null-builds' than on full rebuilds.
I agree. I have posted an email to the scons-list. Let us see what
they think about it.
Cheers,
Bo
On Tue, May 09, 2006 at 12:48:16PM +0200, Lars Gullik Bjønnes wrote:
> "Bo Peng" <[EMAIL PROTECTED]> writes:
>
> | Dear list,
> |
> | *Please* just put cold comparison data in this thread. No discussion
> | and debates. (Open another thread if needed).
> |
> | On my dual processor Xeon 2.8G Linu
On Mon, May 08, 2006 at 11:19:49PM +0200, Joost Verburg wrote:
> Andre Poenitz wrote:
> >Last time the Windows developers wanted to have .vcproj files.
> >
> >They got them.
>
> If compilation with MSVC++ worked, the vcproj files would be very
> useful. However, there are still incompatibilities
On Tue, May 09, 2006 at 12:07:32AM +0200, Michael Gerz wrote:
> Please have a look at the patch and tell me whether it is OK. Its
> overall objective is to make things simpler and clearer.
I am not too happy about the additional #include in insetbase.h,
but as I've never really timed LyX compilat
On Tue, May 09, 2006 at 12:04:44PM -0500, Bo Peng wrote:
> I am too new to scons to give a full solution here. Here are some of
> my opinions:
>
> 1. The check content (md5) approach is better than autotools since
> time stamp can be easily changed and may trigger unnecessary rebuilds.
Well, if t
On Mon, May 08, 2006 at 11:57:24PM +0100, John Levon wrote:
> On Tue, May 09, 2006 at 12:07:32AM +0200, Michael Gerz wrote:
>
> > I must confess that this patch will break CT in some cases
>
> Why is there such pushback against making branches for stuff that's
> *known* broken?
Because maintaini
On Tue, May 09, 2006 at 11:21:04AM +0200, Georg Baum wrote:
> John and Lars,
>
> you both did not directly answer Michaels question. So what should he do
> now? IMHO a simple "yes", "no", or "yes, but only in a separate branch"
> would be in order.
I am neither John nor Lars, but if Micheal has a
On Tue, May 09, 2006 at 11:08:21AM -0500, Bo Peng wrote:
> Vim is *the* editing tool for me. *You can tell from the first line of
> every SCons* files).
Why is this needed btw?
Can't you use autocmd for it?
Andre'
On Mon, May 08, 2006 at 10:35:34PM +0200, Abdelrazak Younes wrote:
> >>>I do welcome the effort to see if the current build system is
> >>>
> >>I don't think your wording is very welcoming, to quote you: "I hate it
> >>already", "please revert", "I don't care one iota", etc...
> >>
> >>I pres
On Mon, May 08, 2006 at 04:35:01PM -0500, Bo Peng wrote:
> Dear list,
>
> *Please* just put cold comparison data in this thread. No discussion
> and debates. (Open another thread if needed).
>
> On my dual processor Xeon 2.8G Linux workstation, I get
>
> scons --config=force -j3 frontend=qt4 qt_
On Mon, May 08, 2006 at 11:31:29PM +0200, Joost Verburg wrote:
> Andre Poenitz wrote:
> >Right, and it took two years or so to change that.
> >
> >I don't think you'd be much faster than Angus _even if
> >everybody agreed_.
>
> OK, so the only remaining possibility is to drop Win98/Me support.
M
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 9 May 2006, Lars Gullik Bjønnes wrote:
> When it comes to testing I will also put forward my meager attempt on
> beginnging to create test cases (please expand on them and create new
> ones).
>
> So far only for a few helper functions, but we should be able to do it
> for larger subsystems as
And you compiled using -O2 with scons, too, right? Otherwise this is
an unfair comparison. I have numbers close to yours on cygwin, but I
cannot convince scons to compile using -O2.
With scons CCFLAGS=-O2, the compile time are about the same. This is
not surprising since the core command g++ tak
On Tue, 9 May 2006, Uwe Stöhr wrote:
> We could have automated tests but many things must be tested manually.
> For example my math manual is build upon sequences to create a formula,
> e.g. the sequence:
> A_u uparrow ^2
> should create an "A" with the subscript "u" and the superscript "2". To
On Tue, 9 May 2006, Uwe Stöhr wrote:
> [EMAIL PROTECTED] wrote:
>
> > I think it's probably unrealistic to create and maintain a big archive
> > with all of this. However, I'm sure few of you will be surprised when I'm
> > now going to suggest how we partially use the wiki for helping with this.
On Tue, May 09, 2006 at 12:41:26PM -0500, Bo Peng wrote:
> >--- SConstruct.orig 2006-05-09 16:29:42.0 +0200
> >+++ SConstruct 2006-05-09 19:24:12.0 +0200
> >@@ -706,7 +706,7 @@
> > if ARGUMENTS.get('mode', default_build_mode) == 'debug':
> > env.Append(CCFLAGS = [])
> > else:
On Tue, May 09, 2006 at 06:29:59PM +0200, Joost Verburg wrote:
> Jean-Marc Lasgouttes wrote:
> >Thanks. So the following (plus removal of cygwin.m4) would be just as
> >good, right?
>
> Yes, but add a new file called windows.m4. My font patch for example
> needs to link against gdi32 on Windows.
--- SConstruct.orig 2006-05-09 16:29:42.0 +0200
+++ SConstruct 2006-05-09 19:24:12.0 +0200
@@ -706,7 +706,7 @@
if ARGUMENTS.get('mode', default_build_mode) == 'debug':
env.Append(CCFLAGS = [])
else:
- env.Append(CCFLAGS = [])
+ env.Append(CCFLAGS = ['-O2'])
Is this '-
On Tue, May 09, 2006 at 11:11:39AM -0500, Bo Peng wrote:
> Before I figure out how to pass -O3, you can edit line 707 of
> Sconstruct and add things like ['O3']. (Not tested)
This one did the trick:
--- SConstruct.orig 2006-05-09 16:29:42.0 +0200
+++ SConstruct 2006-05-09 19:24:12.0
BTW what's the problem with aspell? I mean, it seems that "spell=aspell"
fails in the final link step (even adding by hand -laspell).
I added that option, and I have spell libraries checked, but did not
add the libraries in. (search spell in SConstructt)
Bo
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
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
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
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,
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
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 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
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
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 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
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
> "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
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
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
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:
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
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
> "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
> "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
> "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
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
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
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
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
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: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
> "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
> "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
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
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
==
> "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> 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
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
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
> "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 >
> 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
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.
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
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
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.
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
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
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
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
"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 +
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 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
> "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
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
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
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" == 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
> "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
1 - 100 of 146 matches
Mail list logo
