Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Mar 29, 2007 at 03:18:53PM +0200, Lars Gullik Bjønnes wrote:
| > Andre Poenitz <[EMAIL PROTECTED]> writes:
| >
| > | On Fri, Mar 23, 2007 at 11:48:21PM +0100, Peter Kümmel wrote:
| > | > Is the something like "configure --enable-final" for the a
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Mar 29, 2007 at 03:23:08PM +0200, Lars Gullik Bjønnes wrote:
| > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| >
| > | > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
| > |
| > | Andre> On Sun, Mar 25, 2007 at 10:31:24PM +0200,
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Mar 29, 2007 at 03:19:54PM +0200, Lars Gullik Bjønnes wrote:
| > lumped/merged files benfits badly from parallel builds...
|
| My machine has very limited parallel capacities. The box itself seem to
| have a few parallel edges but I am afraid, t
Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | More data, mathed this time.
> |
> | 'Lumped' means a Mathed.C #include'ing everything else.
> |
> | Times are real/user/sys.
> |
> |Now Lumped
> |
Lars Gullik Bjønnes wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> | Enrico Forestieri wrote:
> | > On Fri, Mar 23, 2007 at 11:48:21PM +0100, Peter Kümmel wrote:
> | >
> | >> Is the something like "configure --enable-final" for the auto tools?
> | >> This is what I've "reinvented" for cmak
On Thu, Mar 29, 2007 at 03:18:53PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Fri, Mar 23, 2007 at 11:48:21PM +0100, Peter Kümmel wrote:
> | > Is the something like "configure --enable-final" for the auto tools?
> | > This is what I've "reinvented" for c
On Thu, Mar 29, 2007 at 03:23:08PM +0200, Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
> |
> | Andre> On Sun, Mar 25, 2007 at 10:31:24PM +0200, Jean-Marc Lasgouttes
> | Andre> wrote:
> | >> > "An
On Thu, Mar 29, 2007 at 03:19:54PM +0200, Lars Gullik Bjønnes wrote:
> lumped/merged files benfits badly from parallel builds...
My machine has very limited parallel capacities. The box itself seem to
have a few parallel edges but I am afraid, that's about it.
Andre'
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Mar 23, 2007 at 11:48:21PM +0100, Peter Kümmel wrote:
| > Is the something like "configure --enable-final" for the auto tools?
| > This is what I've "reinvented" for cmake.
|
| I think we should just go for explicit "master files":
|
| 19 lines
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
|
| Andre> On Sun, Mar 25, 2007 at 10:31:24PM +0200, Jean-Marc Lasgouttes
| Andre> wrote:
| >> > "Andre" == Andre Poenitz
| >> <[EMAIL PROTECTED]> writes:
| >>
| Andre> libtool is a
Andre Poenitz <[EMAIL PROTECTED]> writes:
| More data, mathed this time.
|
| 'Lumped' means a Mathed.C #include'ing everything else.
|
| Times are real/user/sys.
|
|Now Lumped
|
| Null build 2.6/1.4/0.9
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Enrico Forestieri wrote:
| > On Fri, Mar 23, 2007 at 11:48:21PM +0100, Peter Kümmel wrote:
| >
| >> Is the something like "configure --enable-final" for the auto tools?
| >> This is what I've "reinvented" for cmake.
| >
| > What do you mean? Something l
Andre Poenitz <[EMAIL PROTECTED]> writes:
| So _not_ using external symbols seems to be worth a try, too.
| Of course that'd mean 'static func()' instead of 'namespace { func() }'
| and that seems to be close blasphemy in this world as well...
Yes. And with the next version of gcc f.ex. anon name
On Mon, Mar 26, 2007 at 03:39:01PM +0100, José Matos wrote:
> On Monday 26 March 2007 2:56:09 pm Andre Poenitz wrote:
> >
> > So can't we just get rid of it _now_? I fail to see whyu everybody has
> > to suffer just to get us one step closer to the ivory tower at the
> > horizon unless there's actu
> "José" == José Matos <[EMAIL PROTECTED]> writes:
José> On Monday 26 March 2007 2:56:09 pm Andre Poenitz wrote:
>> So can't we just get rid of it _now_? I fail to see whyu everybody
>> has to suffer just to get us one step closer to the ivory tower at
>> the horizon unless there's actually a
On Monday 26 March 2007 2:56:09 pm Andre Poenitz wrote:
>
> So can't we just get rid of it _now_? I fail to see whyu everybody has
> to suffer just to get us one step closer to the ivory tower at the
> horizon unless there's actually a bigger leap already in the pipe.
Even although I sympathise
Andre Poenitz wrote:
On Fri, Mar 23, 2007 at 09:28:24AM +0100, Georg Baum wrote:
Andre Poenitz wrote:
I just ttried binutils from cvs and got:
real0m58.744s
user0m8.969s
sys 0m2.604s
'top' shows a load of 1.3 (with nothing else reallyh running), at most
25% CPU and plenty
On Mon, Mar 26, 2007 at 09:27:46AM +0200, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Andre> On Sun, Mar 25, 2007 at 10:31:24PM +0200, Jean-Marc Lasgouttes
> Andre> wrote:
> >> > "Andre" == Andre Poenitz
> >> <[EMAIL PROTECTED]> writes:
> >>
>
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Sun, Mar 25, 2007 at 10:32:49PM +0200, Jean-Marc Lasgouttes
Andre> wrote:
>> > "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]>
>> writes:
>>
Jürgen> Peter Kümmel wrote:
>> >> > PS: How's "Bordmittel" translated into Engli
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Sun, Mar 25, 2007 at 10:31:24PM +0200, Jean-Marc Lasgouttes
Andre> wrote:
>> > "Andre" == Andre Poenitz
>> <[EMAIL PROTECTED]> writes:
>>
Andre> libtool is a waste of time in the year 2007. That's certainly
Andre> just my op
On Sun, 25 Mar 2007, Andre Poenitz wrote:
On Sun, Mar 25, 2007 at 09:22:51PM +0200, [EMAIL PROTECTED] wrote:
PS: How's "Bordmittel" translated into English?
What's the context where it's used? (I get a feeling it's means something
like "medhavda resurser" in Swedish, i.e. resources etc you ha
Georg Baum wrote:
> Am Sonntag, 25. März 2007 15:31 schrieb Abdelrazak Younes:
>
>> My point is that CMake generated Makefiles are probably faster than
>> autotools generated ones.
>
> Last time I tried cmake the version of cmake on my box (debian etch) was
> too old. That was a showstopper for
On Sun, Mar 25, 2007 at 09:22:51PM +0200, [EMAIL PROTECTED] wrote:
> PS: How's "Bordmittel" translated into English?
>
> What's the context where it's used? (I get a feeling it's means something
> like "medhavda resurser" in Swedish, i.e. resources etc you had with you).
["mitgehabte Ressour
On Sun, Mar 25, 2007 at 10:32:49PM +0200, Jean-Marc Lasgouttes wrote:
> > "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
>
> Jürgen> Peter Kümmel wrote:
> >> > PS: How's "Bordmittel" translated into English?
> >>
> >> Leo has no translation :(
>
> Jürgen> "one's own resources" (D
On Sun, Mar 25, 2007 at 10:31:24PM +0200, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Andre> libtool is a waste of time in the year 2007. That's certainly
> Andre> just my opinion, but anyway. I also believe the kind of
> Andre> variations between d
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
Jürgen> Peter Kümmel wrote:
>> > PS: How's "Bordmittel" translated into English?
>>
>> Leo has no translation :(
Jürgen> "one's own resources" (DUDEN/Oxford).
Ahh, you mean "les moyens du bord" !
JMarc
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> libtool is a waste of time in the year 2007. That's certainly
Andre> just my opinion, but anyway. I also believe the kind of
Andre> variations between different version of Unix leading to and
Andre> rectifying the existance of autot
On Sun, 25 Mar 2007, Andre Poenitz wrote:
On Sun, Mar 25, 2007 at 01:42:25PM +0200, Jürgen Spitzmüller wrote:
Peter Kümmel wrote:
PS: How's "Bordmittel" translated into English?
Leo has no translation :(
"one's own resources" (DUDEN/Oxford).
Urm, yes... does not sound the same... not the
On Sun, Mar 25, 2007 at 03:31:57PM +0200, Abdelrazak Younes wrote:
> >Still, MSVC8 doesn't run on *nix.
>
> Maybe with wine? :-)
Doesn't work at all, I tried that already. [I guess the compiler alone
would work, but it's not the compiler that makes VS2005 'great'... (even
if the compiler is prett
On Sun, Mar 25, 2007 at 01:42:25PM +0200, Jürgen Spitzmüller wrote:
> Peter Kümmel wrote:
> > > PS: How's "Bordmittel" translated into English?
> >
> > Leo has no translation :(
>
> "one's own resources" (DUDEN/Oxford).
Urm, yes... does not sound the same... not the feeling of being alone
on the
Am Sonntag, 25. März 2007 15:31 schrieb Abdelrazak Younes:
> My point is that CMake generated Makefiles are probably faster than
> autotools generated ones.
Last time I tried cmake the version of cmake on my box (debian etch) was
too old. That was a showstopper for me.
> Maybe there's somethin
Andre Poenitz wrote:
On Sat, Mar 24, 2007 at 10:55:58PM +0100, Abdelrazak Younes wrote:
Angus Leeming wrote:
Andre Poenitz <[EMAIL PROTECTED]> writes:
Each time I try to get back to work on LyX I am appalled by the
time it takes to compile and link.
Agreed.
Testcase is src/graphics. Pretty
Peter Kümmel wrote:
> > PS: How's "Bordmittel" translated into English?
>
> Leo has no translation :(
"one's own resources" (DUDEN/Oxford).
Jürgen
On Sat, 24 Mar 2007, Peter Kümmel wrote:
PS: How's "Bordmittel" translated into English?
Leo has no translation :(
How about something like 'a utility that is built in to the system', i.e.
built-in utility? (Babelfish says 'On-board means')
/C
--
Christian Ridderström, +46-8-768 39 44
On Sat, Mar 24, 2007 at 10:55:58PM +0100, Abdelrazak Younes wrote:
> Angus Leeming wrote:
> >Andre Poenitz <[EMAIL PROTECTED]> writes:
> >>Each time I try to get back to work on LyX I am appalled by the
> >>time it takes to compile and link.
> >
> >Agreed.
> >
> >>Testcase is src/graphics. Pretty s
Andre Poenitz wrote:
On Fri, Mar 23, 2007 at 12:06:27AM +0100, Peter Kümmel wrote:
There's a
#define CursorShape 0
in X.h.
The usual workaround is to put
#undef CursorShape
after the last X related #include.
I wonder, however, how this define leaks into our code. IIRC there was
Angus Leeming wrote:
Andre Poenitz <[EMAIL PROTECTED]> writes:
Each time I try to get back to work on LyX I am appalled by the
time it takes to compile and link.
Agreed.
Testcase is src/graphics. Pretty selfcontained, modern C++ the
way we like it. A total of 2608 lines in 11 *.C files.
N
On Sat, Mar 24, 2007 at 01:04:13PM +0100, Peter Kümmel wrote:
> > Ok, just using MathedInsets.C for all insets and MathedCore.C for the
> > rest yields:
> >
> >
> > Now Lumped Lumped/2
> >
> > Null build 2.6/1.4/0.9
Peter Kümmel wrote:
> Andre Poenitz wrote:
>> On Sat, Mar 24, 2007 at 09:33:47AM +0100, Andre Poenitz wrote:
>>> More data, mathed this time.
>>>
>>> 'Lumped' means a Mathed.C #include'ing everything else.
>>>
>>> Times are real/user/sys.
>>>
>>>Now Lumpe
Andre Poenitz wrote:
> On Sat, Mar 24, 2007 at 09:33:47AM +0100, Andre Poenitz wrote:
>> More data, mathed this time.
>>
>> 'Lumped' means a Mathed.C #include'ing everything else.
>>
>> Times are real/user/sys.
>>
>>Now Lumped
>>
On Sat, Mar 24, 2007 at 10:26:27AM +0100, Peter Kümmel wrote:
> Really? see my last mail, hope you don't prove me wrong ;)
Doesn't look bad, however, needs to be auto generated as anything with
more than a line per file starts getting more difficult to maintain.
./configure (and ./config.status -
Peter Kümmel wrote:
> Peter Kümmel wrote:
>> Andre Poenitz wrote:
>>> More data, mathed this time.
>>>
>>> 'Lumped' means a Mathed.C #include'ing everything else.
>>>
>>> Times are real/user/sys.
>>>
>>>Now Lumped
>>>
>>> N
On Sat, Mar 24, 2007 at 09:33:47AM +0100, Andre Poenitz wrote:
>
> More data, mathed this time.
>
> 'Lumped' means a Mathed.C #include'ing everything else.
>
> Times are real/user/sys.
>
>Now Lumped
>
> Null build
Andre Poenitz wrote:
> On Sat, Mar 24, 2007 at 09:47:00AM +0100, Peter Kümmel wrote:
>> Andre Poenitz wrote:
>>> More data, mathed this time.
>>>
>>> 'Lumped' means a Mathed.C #include'ing everything else.
>>>
>>> Times are real/user/sys.
>>>
>>>Now Lumpe
Peter Kümmel wrote:
> Andre Poenitz wrote:
>> More data, mathed this time.
>>
>> 'Lumped' means a Mathed.C #include'ing everything else.
>>
>> Times are real/user/sys.
>>
>>Now Lumped
>>
>> Null build 2.6/1.4/0.9
On Sat, Mar 24, 2007 at 09:47:00AM +0100, Peter Kümmel wrote:
> Andre Poenitz wrote:
> > More data, mathed this time.
> >
> > 'Lumped' means a Mathed.C #include'ing everything else.
> >
> > Times are real/user/sys.
> >
> >Now Lumped
> >
Andre Poenitz wrote:
> More data, mathed this time.
>
> 'Lumped' means a Mathed.C #include'ing everything else.
>
> Times are real/user/sys.
>
>Now Lumped
>
> Null build 2.6/1.4/0.91.6/1.3/0.3
>
More data, mathed this time.
'Lumped' means a Mathed.C #include'ing everything else.
Times are real/user/sys.
Now Lumped
Null build 2.6/1.4/0.91.6/1.3/0.3
Full rebuild 1
On Fri, Mar 23, 2007 at 11:48:21PM +0100, Peter Kümmel wrote:
> Is the something like "configure --enable-final" for the auto tools?
> This is what I've "reinvented" for cmake.
I think we should just go for explicit "master files":
19 lines added, 59 removed, almost the same performance gain as
On Sat, Mar 24, 2007 at 12:54:33AM +0100, Peter Kümmel wrote:
> Enrico Forestieri wrote:
> > On Fri, Mar 23, 2007 at 11:48:21PM +0100, Peter Kümmel wrote:
> >
> >> Is the something like "configure --enable-final" for the auto tools?
> >> This is what I've "reinvented" for cmake.
> >
> > What do y
Peter Kümmel wrote:
> Enrico Forestieri wrote:
>>> I assume building would also be -at least two times-
>>> faster with cygwin. ;)
>> I feel like crying when I hear about full compile times below
>> the hour ;)
>>
>
> The fastest full compile takes here (2GHz, 1core, 512MB)
> 3 min 40 sec ;)
cygw
Enrico Forestieri wrote:
> On Sat, Mar 24, 2007 at 12:54:33AM +0100, Peter Kümmel wrote:
>
>> Enrico Forestieri wrote:
>>> On Fri, Mar 23, 2007 at 11:48:21PM +0100, Peter Kümmel wrote:
>>>
Is the something like "configure --enable-final" for the auto tools?
This is what I've "reinvented"
On Sat, Mar 24, 2007 at 12:54:33AM +0100, Peter Kümmel wrote:
> Enrico Forestieri wrote:
> > On Fri, Mar 23, 2007 at 11:48:21PM +0100, Peter Kümmel wrote:
> >
> >> Is the something like "configure --enable-final" for the auto tools?
> >> This is what I've "reinvented" for cmake.
> >
> > What do
Enrico Forestieri wrote:
> On Fri, Mar 23, 2007 at 11:48:21PM +0100, Peter Kümmel wrote:
>
>> Is the something like "configure --enable-final" for the auto tools?
>> This is what I've "reinvented" for cmake.
>
> What do you mean? Something like --release, perhaps? In this case,
> I don't think so
On Fri, Mar 23, 2007 at 11:48:21PM +0100, Peter Kümmel wrote:
> Is the something like "configure --enable-final" for the auto tools?
> This is what I've "reinvented" for cmake.
What do you mean? Something like --release, perhaps? In this case,
I don't think so, but --disable-debug, --disable-stdl
Enrico Forestieri wrote:
> On Fri, Mar 23, 2007 at 06:22:57PM +0100, Andre Poenitz wrote:
>> On Fri, Mar 23, 2007 at 12:28:20PM +0100, Enrico Forestieri wrote:
>
>>> BTW, I think that Xlib.h must be present on Andre's system...
>> Urm. yes. But not xlib.h...
>
> I had got the the sarcasm in your
On Fri, Mar 23, 2007 at 06:22:57PM +0100, Andre Poenitz wrote:
> On Fri, Mar 23, 2007 at 12:28:20PM +0100, Enrico Forestieri wrote:
> > BTW, I think that Xlib.h must be present on Andre's system...
>
> Urm. yes. But not xlib.h...
I had got the the sarcasm in your answer and was provoking you. Af
Enrico Forestieri wrote:
> On Fri, Mar 23, 2007 at 08:51:57AM +0100, Peter Kümmel wrote:
>> Andre Poenitz wrote:
>>> On Fri, Mar 23, 2007 at 12:06:27AM +0100, Peter Kümmel wrote:
Merging qt4 on linux does not work, because xlib.h defines some symbols
>>> There is no xlib.h on my system.
>>>
>>
On Fri, Mar 23, 2007 at 12:28:20PM +0100, Enrico Forestieri wrote:
> On Fri, Mar 23, 2007 at 08:51:57AM +0100, Peter Kümmel wrote:
> > Andre Poenitz wrote:
> > > On Fri, Mar 23, 2007 at 12:06:27AM +0100, Peter Kümmel wrote:
> > >> Merging qt4 on linux does not work, because xlib.h defines some symb
On Fri, Mar 23, 2007 at 09:28:24AM +0100, Georg Baum wrote:
> Andre Poenitz wrote:
>
> > I just ttried binutils from cvs and got:
> >
> > real0m58.744s
> > user0m8.969s
> > sys 0m2.604s
> >
> > 'top' shows a load of 1.3 (with nothing else reallyh running), at most
> > 25% CPU and ple
On Fri, Mar 23, 2007 at 08:51:57AM +0100, Peter Kümmel wrote:
> Andre Poenitz wrote:
> > On Fri, Mar 23, 2007 at 12:06:27AM +0100, Peter Kümmel wrote:
> >> Merging qt4 on linux does not work, because xlib.h defines some symbols
> >
> > There is no xlib.h on my system.
> >
> >> and gcc couldn't re
On Fri, Mar 23, 2007 at 08:51:57AM +0100, Peter Kümmel wrote:
> Andre Poenitz wrote:
> > On Fri, Mar 23, 2007 at 12:06:27AM +0100, Peter Kümmel wrote:
> >> Merging qt4 on linux does not work, because xlib.h defines some symbols
> >
> > There is no xlib.h on my system.
> >
> >> and gcc couldn't re
Andre Poenitz wrote:
> I just ttried binutils from cvs and got:
>
> real0m58.744s
> user0m8.969s
> sys 0m2.604s
>
> 'top' shows a load of 1.3 (with nothing else reallyh running), at most
> 25% CPU and plenty of RAM free. So what happens there?
Seems they did some optimization :-) I
Andre Poenitz wrote:
> On Fri, Mar 23, 2007 at 12:06:27AM +0100, Peter Kümmel wrote:
>> Merging qt4 on linux does not work, because xlib.h defines some symbols
>
> There is no xlib.h on my system.
>
>> and gcc couldn't resolve symbols, which looks like a gcc bug.
>
> I know you won't believe me,
On Fri, Mar 23, 2007 at 12:06:27AM +0100, Peter Kümmel wrote:
> Merging qt4 on linux does not work, because xlib.h defines some symbols
There is no xlib.h on my system.
> and gcc couldn't resolve symbols, which looks like a gcc bug.
I know you won't believe me, but gcc bugs are less rare than
yo
On Thu, Mar 22, 2007 at 09:30:42AM +0100, Georg Baum wrote:
> Andre Poenitz wrote:
>
> > Well, I actually tried to fix a bug or two, because I want 1.5 to ship,
> > but then the compile time/link time issue got in the way. I simply
> > won't spend several minutes waiting for each roundtrip.
>
> T
Andre Poenitz wrote:
> On Wed, Mar 21, 2007 at 10:01:58PM +0100, Peter Kümmel wrote:
>> just as you suggest? Ie, let the makefile perform the concatenation?
> It's an interesting suggestion.
I've added this feature to the cmake build:
cmake ../trunk/development/cmake -Dme
On Thu, Mar 22, 2007 at 09:30:42AM +0100, Georg Baum wrote:
> Andre Poenitz wrote:
>
> > Well, I actually tried to fix a bug or two, because I want 1.5 to ship,
> > but then the compile time/link time issue got in the way. I simply
> > won't spend several minutes waiting for each roundtrip.
>
> T
On Thu, Mar 22, 2007 at 10:19:28AM +0100, [EMAIL PROTECTED] wrote:
> On Tue, 20 Mar 2007, Andre Poenitz wrote:
>
> >>No, I just felt that the equivalent of 40 pages of code is a bit much in a
> >>single chunk. It's just my opinion.
> >
> >It might be. But the real question is:
> >
> > Does this fe
On Tue, 20 Mar 2007, Andre Poenitz wrote:
No, I just felt that the equivalent of 40 pages of code is a bit much in a
single chunk. It's just my opinion.
It might be. But the real question is:
Does this feeling outweigh losing 15s each time you run make?
I don't really have anything more to
José Matos wrote:
> On Wednesday 21 March 2007 8:14:50 am Georg Baum wrote:
>> PS: I fail to understand either why you bring up issues like compile
>> times and rpmdist. I thought that the goal was to get out 1.5.0 ASAP, but
>> obviously this is not true and it is more important to discuss some
>>
Andre Poenitz wrote:
> Well, I actually tried to fix a bug or two, because I want 1.5 to ship,
> but then the compile time/link time issue got in the way. I simply
> won't spend several minutes waiting for each roundtrip.
This is faster here. If I touch any file and recompile I get 47 seconds, a
On Wed, Mar 21, 2007 at 10:01:58PM +0100, Peter Kümmel wrote:
> just as you suggest? Ie, let the makefile perform the concatenation?
> >>> It's an interesting suggestion.
> >> I've added this feature to the cmake build:
> >>
> >> cmake ../trunk/development/cmake -Dmerge=1
> >>
> >> then al
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> Peter Kümmel wrote:
>> files multiple merged (in minutes)
>> -- cmake msvc debug 17
>> 9 cmake msvc release 19 10 Linux cmake 21 11 Linux auto/make 54 --
>>
>>
>> Is make really so slow?
Peter Kümmel wrote:
>
> files multiple merged (in minutes)
> --
> cmake msvc debug 17 9
> cmake msvc release 19 10
> Linux cmake 21 11
> Linux auto/make 54 --
>
>
> Is make really so slow? I've cal
Peter Kümmel wrote:
> Linux auto/make 54 --
It's not that slow because of linking.
Linking takes only 30 seconds or so.
Peter
Andre Poenitz wrote:
> On Wed, Mar 21, 2007 at 12:14:49AM +0100, Peter Kümmel wrote:
>> Andre Poenitz wrote:
>>> On Tue, Mar 20, 2007 at 06:45:29PM +, Angus Leeming wrote:
Andre Poenitz <[EMAIL PROTECTED]> writes:
Given that your solution to the problems that the compiler has with the
On Wed, Mar 21, 2007 at 06:03:04PM +, José Matos wrote:
> On Sunday 18 March 2007 6:42:05 am Andre Poenitz wrote:
> > PS: For some strange reason I have the impression that whenever LyX
> > development get the choice between two options, it chooses the one that
> > hurt most.
>
> I remember th
Peter Kümmel wrote:
> Andre Poenitz wrote:
>> On Wed, Mar 21, 2007 at 12:14:49AM +0100, Peter Kümmel wrote:
>>> Andre Poenitz wrote:
On Tue, Mar 20, 2007 at 06:45:29PM +, Angus Leeming wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> Given that your solution to the problems tha
Andre Poenitz wrote:
> On Wed, Mar 21, 2007 at 12:14:49AM +0100, Peter Kümmel wrote:
>> Andre Poenitz wrote:
>>> On Tue, Mar 20, 2007 at 06:45:29PM +, Angus Leeming wrote:
Andre Poenitz <[EMAIL PROTECTED]> writes:
Given that your solution to the problems that the compiler has with the
On Sunday 18 March 2007 6:42:05 am Andre Poenitz wrote:
> PS: For some strange reason I have the impression that whenever LyX
> development get the choice between two options, it chooses the one that
> hurt most.
I remember that sometimes you were involved in some of those choices. ;-)
--
José A
On Wednesday 21 March 2007 8:14:50 am Georg Baum wrote:
> PS: I fail to understand either why you bring up issues like compile times
> and rpmdist. I thought that the goal was to get out 1.5.0 ASAP, but
> obviously this is not true and it is more important to discuss some
> fundamental changes like
Andre Poenitz wrote:
On Wed, Mar 21, 2007 at 12:30:32AM +0200, Dov Feldstern wrote:
[I am surprised you are able to link LyX. After all, swapping during.
linking was the reason I bought my laptop with 512 MB to _link_ LyX,
not to compile it. Are you sure you measure what you think you do?]
It i
On Wed, Mar 21, 2007 at 09:14:50AM +0100, Georg Baum wrote:
> PS: I fail to understand either why you bring up issues like compile times
> and rpmdist. I thought that the goal was to get out 1.5.0 ASAP, but
> obviously this is not true and it is more important to discuss some
> fundamental changes
Andre Poenitz wrote:
> On Wed, Mar 21, 2007 at 12:14:49AM +0100, Peter Kümmel wrote:
>> Index: src/support/filetools.C
>> ===
>> --- src/support/filetools.C (Revision 17495)
>> +++ src/support/filetools.C (Arbeitskopie)
>> @@ -67,7
Andre Poenitz wrote:
> On Wed, Mar 21, 2007 at 12:30:32AM +0200, Dov Feldstern wrote:
>> >
>> >>[I am surprised you are able to link LyX. After all, swapping during.
>> >>linking was the reason I bought my laptop with 512 MB to _link_ LyX,
>> >>not to compile it. Are you sure you measure what you
On Wed, Mar 21, 2007 at 12:14:49AM +0100, Peter Kümmel wrote:
> Andre Poenitz wrote:
> > On Tue, Mar 20, 2007 at 06:45:29PM +, Angus Leeming wrote:
> >> Andre Poenitz <[EMAIL PROTECTED]> writes:
> >> Given that your solution to the problems that the compiler has with these
> >> 11
> >> files
On Wed, Mar 21, 2007 at 12:30:32AM +0200, Dov Feldstern wrote:
> >
> >>[I am surprised you are able to link LyX. After all, swapping during.
> >>linking was the reason I bought my laptop with 512 MB to _link_ LyX,
> >>not to compile it. Are you sure you measure what you think you do?]
> >
> >It is
Andre Poenitz wrote:
> On Tue, Mar 20, 2007 at 06:45:29PM +, Angus Leeming wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>> Each time I try to get back to work on LyX I am appalled by the
>>> time it takes to compile and link.
>> Agreed.
>>
>>> Testcase is src/graphics. Pretty selfcontai
[I am surprised you are able to link LyX. After all, swapping during.
linking was the reason I bought my laptop with 512 MB to _link_ LyX,
not to compile it. Are you sure you measure what you think you do?]
It is indeed the linking stage which is failing when I compile in
debugging symbols.
On Tue, Mar 20, 2007 at 06:45:29PM +, Angus Leeming wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> > Each time I try to get back to work on LyX I am appalled by the
> > time it takes to compile and link.
>
> Agreed.
>
> > Testcase is src/graphics. Pretty selfcontained, modern C++ the
>
Andre Poenitz <[EMAIL PROTECTED]> writes:
> Each time I try to get back to work on LyX I am appalled by the
> time it takes to compile and link.
Agreed.
> Testcase is src/graphics. Pretty selfcontained, modern C++ the
> way we like it. A total of 2608 lines in 11 *.C files.
> Now, cp *.C Graphic
On Tue, Mar 20, 2007 at 02:28:13PM +0100, [EMAIL PROTECTED] wrote:
> >Do you really see this less desirable as having a 2600 lines file lying
> >around somewhere in a corner you never work on?
>
> My only concern is with the question of how difficult it is to
> understand and maintain the code.
On Sun, 18 Mar 2007, Andre Poenitz wrote:
did this for the NSIS stuff): assuming 70 lines per page, those 2608
lines would become about 40 pages. Personally I think that'd be too
much as a single document, but I assume you're not suggesting it all go
into a single file, but rather a small set
On Mon, Mar 19, 2007 at 08:07:55PM +0100, Andre Poenitz wrote:
> On Mon, Mar 19, 2007 at 06:20:54PM +0100, Enrico Forestieri wrote:
> > > A reality check seems to be in order. Compiling the combined
> > > Graphics.C takes 140 MB with profile information, and so does
> > > the former GraphicsConver
On Mon, Mar 19, 2007 at 06:20:54PM +0100, Enrico Forestieri wrote:
> > A reality check seems to be in order. Compiling the combined
> > Graphics.C takes 140 MB with profile information, and so does
> > the former GraphicsConverter.C. buffer.C takes 145 MB btw. So
> > the size of the compiler proces
On Mon, Mar 19, 2007 at 04:32:41PM +0100, Andre Poenitz wrote:
> On Mon, Mar 19, 2007 at 11:56:51AM +0100, Enrico Forestieri wrote:
> > On Mon, Mar 19, 2007 at 11:32:57AM +0100, Helge Hafting wrote:
> >
> > > Andre Poenitz wrote:
> > > [...]
> > > > Status quo:
> > > >
> > > > (plain g++) touch
On Mon, Mar 19, 2007 at 04:32:41PM +0100, Andre Poenitz wrote:
> The innocent errorlist.C of 32 lines is 21481 lines after the
> preprocessor run. Buffer.C goes up from 1730 to 93380. So only a
> marginal part (0.15% and 18%, respectively) of what the compiler sees
> is actual LyX code. And, what
On Mon, Mar 19, 2007 at 04:36:08PM +0100, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> >> Moreover, I cannot anymore compile with debugging symbols because I
> >> get out of memory errors, and have to selectively compile single
> >> files with -g. I
On Mon, Mar 19, 2007 at 01:47:13PM +0100, Enrico Forestieri wrote:
> The swap is already used when needed, and indeed buffer.C takes forever
> to be compiled.
The size of the compiler process does not (primarily) depend on the input
size (i.e. the size of the compilation unit) and even less on the
1 - 100 of 138 matches
Mail list logo
