Anyone interested in using the tool described here to find bugs in our
Qt-related code?
https://www.kdab.com/uncovering-32-qt-best-practices-compile-time-clazy/
Scott
signature.asc
Description: PGP signature
Am Mittwoch, 26. November 2014 um 11:21:06, schrieb Jean-Marc Lasgouttes
> Le 25/11/2014 19:39, Kornel Benko a écrit :
> > The way it is now in cmake is to recompile every time the date changes.
> > a.) Create temporary file lyx_date.tmp
> > b.) check if different to lyx_date.h
> > b1.) overw
Le 25/11/2014 19:39, Kornel Benko a écrit :
The way it is now in cmake is to recompile every time the date changes.
a.) Create temporary file lyx_date.tmp
b.) check if different to lyx_date.h
b1.) overwrite if yes.
Currently we display both date and time in lyx -version. The time has
h
Am Dienstag, 25. November 2014 um 19:04:45, schrieb Jean-Marc Lasgouttes
> Le 25/11/2014 11:55, Kornel Benko a écrit :
> > Am Montag, 24. November 2014 um 22:04:10, schrieb Jean-Marc Lasgouttes
> >
> >> I have not dont anything like lyx_date.h yet. How do you use it? Is it
> >> the build date?
Le 25/11/2014 11:55, Kornel Benko a écrit :
Am Montag, 24. November 2014 um 22:04:10, schrieb Jean-Marc Lasgouttes
I have not dont anything like lyx_date.h yet. How do you use it? Is it
the build date?
It is the build date. Similar to commit_hash.
That's what I thought. It is actually the
; Autotools: read git commit hash at compile time
> >
> > Also do as cmake to avoid full recompilation when the hash changes.
>
> Kornel,
>
> I have not dont anything like lyx_date.h yet. How do you use it? Is it
> the build date?
It is the build date. Similar to
Le 24/11/2014 22:00, Jean-Marc Lasgouttes a écrit :
commit 0b09424017866d0f1d9dfff8cb54cedaf17b99aa
Author: Jean-Marc Lasgouttes
Date: Mon Nov 24 18:39:18 2014 +0100
Autotools: read git commit hash at compile time
Also do as cmake to avoid full recompilation when the hash changes
On Mon, Dec 2, 2013 at 8:07 AM, Kornel Benko wrote:
> BTW, we do not come very far compiling with -Werror.
True. But there are not too many of these. And I think the auto_ptr
warnings (now errors) only occur with -DLYX_ENABLE_CXX11
There are many more warnings using Clang.
It would be nice to
ov 30, 2013 at 7:08 PM, Scott Kostyshak
> > wrote:
> >
> > >
> >
> > > > commit 374cf6a39f321c7843b36aab242e0852b01887b8
> >
> > > > Author: Scott Kostyshak
> >
> > > > Date: Fri Nov 29 21:08:48 2013 -0500
> >
> > >
3b36aab242e0852b01887b8
>
> > > Author: Scott Kostyshak
>
> > > Date: Fri Nov 29 21:08:48 2013 -0500
>
> > >
>
> > > CMake: allow compile-time C++ flags to be set
>
> > >
>
> > > For example, one could run CMake as
Am Montag, 2. Dezember 2013 um 09:00:30, schrieb Vincent van Ravesteijn
> On Sat, Nov 30, 2013 at 7:08 PM, Scott Kostyshak wrote:
>
> > commit 374cf6a39f321c7843b36aab242e0852b01887b8
> > Author: Scott Kostyshak
> > Date: Fri Nov 29 21:08:48 2013 -0500
> >
>
On Sat, Nov 30, 2013 at 7:08 PM, Scott Kostyshak wrote:
> commit 374cf6a39f321c7843b36aab242e0852b01887b8
> Author: Scott Kostyshak
> Date: Fri Nov 29 21:08:48 2013 -0500
>
> CMake: allow compile-time C++ flags to be set
>
> For example, one could run CMake as f
On Wednesday 07 April 2010 09:42:54 Jean-Marc Lasgouttes wrote:
> Yes, it is very common in free software (at least those who get to these
> big numbers).
>
> JMarc
I would go far and say that this is the rule. :-)
Something like major.minor.bugfix where each mark (major, minor and bugfix) is
a
Jack Desert writes:
> Ah, it seems I downloaded 1.9 thinking it was newer than 1.10. (As a
> decimal number it looks bigger.) Is it conventional for 1.9 to be
> lesser than 1.10? If so, I guess I'll have to get used to it.
Yes, it is very common in free software (at least those who get to these
b
El Tue, 06 Apr 2010 15:15:12 +0200
Jean-Marc Lasgouttes escribió:
> Jack Desert writes:
>
> > Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
> > MB RAM Compaq Presario, and it takes about 45 minutes. How long should
> > it take?
>
> Final linking is probably the problem.
El Tue, 6 Apr 2010 18:46:54 +0200
"Vincent van Ravesteijn - TNW" escribió:
>
> >> Did you run autogen.sh first?
> >>
> >> BH
> >
> >Actually, autogen is throwing an error/warning:
> >
> >Using automake (GNU automake) 1.9
> >Using autoconf (GNU Autoconf) 2.64
> >Building macros...
> >Building con
>> Did you run autogen.sh first?
>>
>> BH
>
>Actually, autogen is throwing an error/warning:
>
>Using automake (GNU automake) 1.9
>Using autoconf (GNU Autoconf) 2.64
>Building macros...
>Building config header template...
>Building Makefile templates...
>configure.ac:29: option `dist-lzma' not re
El Tue, 6 Apr 2010 10:11:19 -0400
BH escribió:
> On Tue, Apr 6, 2010 at 10:04 AM, Jack Desert wrote:
> > El Tue, 06 Apr 2010 15:15:12 +0200
> > Jean-Marc Lasgouttes escribió:
> >> Jack Desert writes:
> >>
> >> > Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
> >> > MB RA
> >
> > Sounds good. I'll try that next.
> >
> > Actually, I downloaded a fresh copy of trunk last night, and it's not
> > finding the makefile, so can't even get to that part.
> >
> > $ ./configure
> > [snipped a bunch of lines]
> > config.status: error: cannot find input file: `Makefile.in'
On Tue, Apr 6, 2010 at 10:04 AM, Jack Desert wrote:
> El Tue, 06 Apr 2010 15:15:12 +0200
> Jean-Marc Lasgouttes escribió:
>> Jack Desert writes:
>>
>> > Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
>> > MB RAM Compaq Presario, and it takes about 45 minutes. How long sho
El Tue, 06 Apr 2010 15:15:12 +0200
Jean-Marc Lasgouttes escribió:
> Jack Desert writes:
>
> > Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
> > MB RAM Compaq Presario, and it takes about 45 minutes. How long should
> > it take?
>
> Final linking is probably the problem.
Jack Desert writes:
> Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
> MB RAM Compaq Presario, and it takes about 45 minutes. How long should
> it take?
Final linking is probably the problem. Try to compile without debug
information (unless you are debugging). That would
>Well, on my Duron 700 with 512 MB, it took several
>hours (and finally crashed).
I guess the memory is the big problem here. I upgraded my machine from
512 MB to 2 GB and compilation times were severely reduced.
Vincent
On 2010-04-06, Jack Desert wrote:
> Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387
> MB RAM Compaq Presario, and it takes about 45 minutes. How long should
> it take?
Well, on my Duron 700 with 512 MB, it took several hours (and finally
crashed).
You can save memory/time i
Is there a faster way to compile LyX? I'm compiling on a 2.0 GHz / 387 MB RAM
Compaq Presario, and it takes about 45 minutes. How long should it take?
-Jack
--
~~~
Jack Desert --Writer, Entrepeneur
Author and Spokesman: www.LetsEATalready.
"Jose' Matos" <[EMAIL PROTECTED]> writes:
| qt gcc4
| real2m48.638s
| user7m57.588s
| sys 1m30.151s
>
| xforms gcc4
| real2m0.747s
| user5m45.744s
| sys 0m59.944s
>
| qt gcc
| real3m5.422s
| user9m44.996s
| sys 1m33.581s
>
| xforms gcc
| real1m55.644s
| user
On Sunday 13 March 2005 23:11, Lars Gullik Bjønnes wrote:
>
> Actually I am more intrerested in the differences than in the acutal
> numbers. (just to put some ice in your bloodstream)
>
> Between frontends and compilers.
$ uname -a
Linux quadOPTERON 2.6.10-1.770_14.rhfc3.atsmp #1 SMP Fri Mar 4 14
"Jose' Matos" <[EMAIL PROTECTED]> writes:
| On Friday 11 March 2005 16:21, Jose' Matos wrote:
>> Following tradition I send the compile times of the qt frontend:
>>
>> $ ./configure --with-frontend=qt ...
>> ...
>> $ time make -j4
>> ...
>> real3m17.863s
>> user9m41.812s
>> sys 1m34.01
On Friday 11 March 2005 16:21, Jose' Matos wrote:
> Following tradition I send the compile times of the qt frontend:
>
> $ ./configure --with-frontend=qt ...
> ...
> $ time make -j4
> ...
> real3m17.863s
> user9m41.812s
> sys 1m34.016s
>
> Oh, if you want to know this is Fedora Core 3
Following tradition I send the compile times of the qt frontend:
$ ./configure --with-frontend=qt ...
...
$ time make -j4
...
real3m17.863s
user9m41.812s
sys 1m34.016s
Oh, if you want to know this is Fedora Core 3 and lyx-1.3.5. ;-)
--
José Abílio
On Thu, Jan 06, 2005 at 08:35:35PM +0100, Lars Gullik Bjønnes wrote:
> With gcc 3.3 as with FC3:
>
> real15m52.640s
> user13m6.642s
> sys 2m11.597s
>
> With gcc 4.0 from gcc cvs:
>
> real10m21.856s
> user8m13.158s
> sys 1m47.379s
>
> debug, stdlib-debug and concept-check
"Jose' Matos" <[EMAIL PROTECTED]> writes:
| On Thursday 06 January 2005 19:35, Lars Gullik Bjønnes wrote:
>> With gcc 3.3 as with FC3:
>
| FC3 comes with gcc 3.4...
FC2 then.
--
Lgb
On Thursday 06 January 2005 19:35, Lars Gullik Bjønnes wrote:
> With gcc 3.3 as with FC3:
FC3 comes with gcc 3.4...
--
José Abílio
With gcc 3.3 as with FC3:
real15m52.640s
user13m6.642s
sys 2m11.597s
With gcc 4.0 from gcc cvs:
real10m21.856s
user8m13.158s
sys 1m47.379s
debug, stdlib-debug and concept-checking turned off. xforms only
--
Lgb
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
| | Lars Gullik Bjønnes wrote:
>>
>>> The 10 seconds or the 30k.
>>> (or perhaps that is close enough to zero for you to see.)
>>
| | Let me put my zoom glasses on: ah, that 0.2% and 0.8% ? ;-)
>>
|
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> The 10 seconds or the 30k.
>> (or perhaps that is close enough to zero for you to see.)
>
| Let me put my zoom glasses on: ah, that 0.2% and 0.8% ? ;-)
>
| Jokes apart, is it less than trivial to test current cvs wit
Lars Gullik BjÃnnes wrote:
> The 10 seconds or the 30k.
> (or perhaps that is close enough to zero for you to see.)
Let me put my zoom glasses on: ah, that 0.2% and 0.8% ? ;-)
Jokes apart, is it less than trivial to test current cvs with new boost to
see if that is what makes the difference? (I
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> | user10m9.080s
>> | sys 0m55.200s
>> 3460834 22008 56464 3539306 36016a src/lyx
>
>> user9m59.590s
>> sys 0m53.140s
>> 3433908 20252 55644 3509804 358e2c src/lyx
>
|
>> This is with boost
Lars Gullik BjÃnnes wrote:
> | user10m9.080s
> | sys 0m55.200s
> 3460834 22008 56464 3539306 36016a src/lyx
> user9m59.590s
> sys 0m53.140s
> 3433908 20252 55644 3509804 358e2c src/lyx
> This is with boost 1.30 and gcc 3.4 prerelease
>
> The Q now is if this is due t
On Tue, Jan 06, 2004 at 12:10:23PM +0100, Lars Gullik Bjønnes wrote:
> But I wouldn't say that the difference is huge.
Indeed. So I'll stop complaining.
Andre'
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Just as a data-point:
>
| real11m17.221s
| user10m9.080s
| sys 0m55.200s
size src/lyx
textdata bss dec hex filename
3460834 22008 56464 3539306 36016a src/lyx
|
| This is with boost release candidate 1.31.0 a
Just as a data-point:
real11m17.221s
user10m9.080s
sys 0m55.200s
This is with boost release candidate 1.31.0 and gcc 3.4 prerelease.
(just the xforms frontend)
I'll do a compile of clean lyx cvs now.
--
Lgb
Just to show the difference between compiler versions and to show that
gcc is moving in the right direction. Note also that 3.3 and 3.4 are a
lot more C++ correct in regard to the C++ standard than 3.2 (but 3.2
is pretty good as well.)
version sizels -l compile time
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| version sizels -l compile time
| gcc 3.2.2 3150291 7937950817m6.396s
| Note that they are not really equal... 3.3.1 and 3.4 is current CVS
| (half a day ago), but 3.2.2 is current CVS + my
44 matches
Mail list logo
