How about adding
#ifdef _USE_PCH
#include
#endif
Even this does not satisfy msvc. msvc replaces things before (and
include) pch.h with precompiled headers generated by pch.cpp, and
leaves one #endif in the .cpp file, which of course results in
trouble. Note that pragma does not work in this ca
On Mon, Jun 19, 2006 at 11:50:10AM -0500, Bo Peng wrote:
> We do not have this in .C either. As I have said, I see no reason why
> not include pch.h.
Because this gets far too expensive on compilers that don't have
precompiled headers.
Andre'
On Mon, Jun 19, 2006 at 09:39:58PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Mon, Jun 19, 2006 at 06:36:25PM +0200, Lars Gullik Bjønnes wrote:
> | > | stdafx.h contains all commonly used headers. msvc knows from a
> | > | compiler flag (or by default) t
On Wed, Jun 21, 2006 at 08:48:08PM +0200, Lars Gullik Bjønnes wrote:
> "Bo Peng" <[EMAIL PROTECTED]> writes:
>
> | > | Unless you can convince me with more benefits of the current approach,
> | >
> | > No, It is _you_ that has to convice me.
> |
> | I have listed benefits and costs, you simply sa
On Mon, Jun 19, 2006 at 11:50:10AM -0500, Bo Peng wrote:
> We do not have this in .C either. As I have said, I see no reason why
> not include pch.h.
Because this gets far too expensive on compilers that don't have
precompiled headers.
pch.h consists of 'commonly used header files'. If I put pc
How do I do that from msvc? I reckon I still have to do that in an
external console right?
You specify it when you create the msvs project. msvs starts scons
which loads the option when it builds lyx. That is to say, you can
still use boost=, nls= etc, just do not use mode=release (debug will
n
Bo Peng wrote:
Another bug report ;-)
When compiling directly from MSVC (by pressing F7), scons is apparently
called with "rebuild=lyx". This is a problem because any modified file
won't be compiled again, only the lyx final linking happens. So I always
have to call scons from a command line.
Another bug report ;-)
When compiling directly from MSVC (by pressing F7), scons is apparently
called with "rebuild=lyx". This is a problem because any modified file
won't be compiled again, only the lyx final linking happens. So I always
have to call scons from a command line.
Patch submitted.
Bo Peng wrote:
Absolutely not... pch is in now way required.
(I have even contemplated removing the support for the autotools
build. Note that autoconf/automake has no support for pch, that is
something I added.)
That is good. I have almost finished a msvc patch. If my tests show no
significant
Absolutely not... pch is in now way required.
(I have even contemplated removing the support for the autotools
build. Note that autoconf/automake has no support for pch, that is
something I added.)
That is good. I have almost finished a msvc patch. If my tests show no
significant performance boo
"Bo Peng" <[EMAIL PROTECTED]> writes:
| I am not quite enthusiastic about pch since my benchmarks show less
| than 10% of performance improvement (autotools). However, I had the
| feeling that to compete with autotools, this is a must have feature
| for scons (among other things like distcheck).
> How about adding
>
> #ifdef _USE_PCH
> #include
> #endif
I think that you could put that in the scons generated "common/config.h"
and stay in peace with Lars and the LyX source code ;-)
That will not work since msvc will scan the source code itself, not
into config.h.
> and change --includ
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Quite frankly I don't think the use of PCH is a panacea. I
Abdelrazak> think it is just an excuse for badly written code. By
Abdelrazak> using forward declaration (class foo) in header you reduce
Abdelrazak> considerab
Bo Peng wrote:
And that is only thing I absolutely refuse. Not a single included
header file should ever be removed from any source because of some
pch.h.
Nothing will be more portable.
How about adding
#ifdef _USE_PCH
#include
#endif
I think that you could put that in the scons generated
And that is only thing I absolutely refuse. Not a single included
header file should ever be removed from any source because of some
pch.h.
Nothing will be more portable.
How about adding
#ifdef _USE_PCH
#include
#endif
and change --include=pch.h to -D_USE_PCH?
Bo
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > Yes. I basically require you to find a find a way to avoid the code
| > intrusion of win-style precompiled headers.
|
| Now my answer is no, there is no way to do msvc/pch without
| modification to the source files themselves. Since the inclusion of
| pch
Yes. I basically require you to find a find a way to avoid the code
intrusion of win-style precompiled headers.
Now my answer is no, there is no way to do msvc/pch without
modification to the source files themselves. Since the inclusion of
pch.h will cost almost nothing (other than intrusiveness
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > | Unless you can convince me with more benefits of the current approach,
| >
| > No, It is _you_ that has to convice me.
|
| I have listed benefits and costs, you simply said "I do not like it".
Yes. I basically require you to find a find a way to avoid
| Unless you can convince me with more benefits of the current approach,
No, It is _you_ that has to convice me.
I have listed benefits and costs, you simply said "I do not like it".
"mainstream"?
Only in your world not mine.
That is the case for all online tutorials, examples, manuals. Ca
"Bo Peng" <[EMAIL PROTECTED]> writes:
| Unless you can convince me with more benefits of the current approach,
No, It is _you_ that has to convice me.
| I would suggest that lyx follows the mainstream and adds pch.h to
| source files.
"mainstream"?
Only in your world not mine.
--
Lg
To me the change to provide pvh for win is just too ugly.
This time, I do not think it is Bill's fault.
You insist on 'non-intrusive pch'. As a result, every source file has
its own full set of headers and can compile normally. When pch is on,
many headers in the source files are shadowed becau
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > > Other votes? JMarc, Georg? (We need to include pch.h in each source
| > > file and remove --include=pch.h)
| >
| > I don't care as long as I don't have to do build system changes afterwards.
|
| The build system change (autotools end) is minimal. A simp
> Other votes? JMarc, Georg? (We need to include pch.h in each source
> file and remove --include=pch.h)
I don't care as long as I don't have to do build system changes afterwards.
The build system change (autotools end) is minimal. A simple deletion
of --include=pch.h in config/common.m4 will
Bo Peng wrote:
>> |
>> | Please decide whether or not we want msvc/pch.
>>
>> My vote then is: No.
>
> Other votes? JMarc, Georg? (We need to include pch.h in each source
> file and remove --include=pch.h)
I don't care as long as I don't have to do build system changes afterwards.
Georg
|
| Please decide whether or not we want msvc/pch.
My vote then is: No.
Other votes? JMarc, Georg? (We need to include pch.h in each source
file and remove --include=pch.h)
| Note that we do not gain much from gcc/pch. my initial benchmark says:
|
| autotools/gcc/pch: 12.36s
| autotools/gcc/n
"Bo Peng" <[EMAIL PROTECTED]> writes:
| On 6/19/06, Bo Peng <[EMAIL PROTECTED]> wrote:
| > > I thought this was were the pch.cpp came in, only used for generating
| > > the pch.pch file.
|
| From what I read
|
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f
On 6/19/06, Bo Peng <[EMAIL PROTECTED]> wrote:
> I thought this was were the pch.cpp came in, only used for generating
> the pch.pch file.
From what I read
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.yu.asp
, it is necessary to change all our source
I thought this was were the pch.cpp came in, only used for generating
the pch.pch file.
My understanding is that pch.cpp is needed for pch.pch, but msvc will
still scan source files for #progma or #include . Passing
include=pch.h does not count.
Bo
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > | How is '#pragma hdrstop' less intrusive than '#include '
| >
| > I thought that the pragma wan only needed in a pch.cpp file, not in
| > all source files.
| >
| >
|
| I am not sure about this one. (Need to read MSDN.) Certainly the
| stopping header me
| How is '#pragma hdrstop' less intrusive than '#include '
I thought that the pragma wan only needed in a pch.cpp file, not in
all source files.
I am not sure about this one. (Need to read MSDN.) Certainly the
stopping header mechanism does not work for --include=pch.h since msvc
need to sca
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Jun 19, 2006 at 06:36:25PM +0200, Lars Gullik Bjønnes wrote:
| > | stdafx.h contains all commonly used headers. msvc knows from a
| > | compiler flag (or by default) that stdafx.h (stopping header) is
| > | pre-processed and skip it.
| >
| > Use
On Mon, Jun 19, 2006 at 06:36:25PM +0200, Lars Gullik Bjønnes wrote:
> | stdafx.h contains all commonly used headers. msvc knows from a
> | compiler flag (or by default) that stdafx.h (stopping header) is
> | pre-processed and skip it.
>
> Use #pragma hdrstop instead.
Looks like I have a really b
On Mon, Jun 19, 2006 at 12:55:07PM +0200, Lars Gullik Bjønnes wrote:
> no. (pch should not be intrusive... bugger off msvc)
Hm? MSVC could automatically include some file pretty much the way
gcc's '-include' works.
Andre'
On Mon, Jun 19, 2006 at 10:43:20AM -0500, Bo Peng wrote:
> >and how will that change if you include pch.h in all the source files,
> >excepti being overly intrusive? or having some files compiled iwth pch
> >and some not...=?
>
> I do not think this is a matter of intrusiveness.
>
> By definition
So if you have ten .h files which of nine needs foo.h then foo.h
cannot be placed in pch.hpp?
Maybe we should say 7/10 in, 6/10 out? :-)
| Unless you want more than commonly used headers in pch.h.
I want commonly used headers but not just the intersection.
I finally see the differences betw
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > And 2. is the thing that smells most foul to me.
| > There must exist another solution.
|
| pch.h means precompiled-headers. Will std_headers.h make you happier?
No it won't.
| (I do not know what afx in stdafx means.)
application framework.
--
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > | As I have said, I see no reason why
| > | not include pch.h.
| >
| > I do.
| >
| > by adding pch.h and removing the now duplicated headers you no longer
| > have control over the actually required headers for that particular
| > source file.
|
| I still
And 2. is the thing that smells most foul to me.
There must exist another solution.
pch.h means precompiled-headers. Will std_headers.h make you happier?
(I do not know what afx in stdafx means.)
Bo
| As I have said, I see no reason why
| not include pch.h.
I do.
by adding pch.h and removing the now duplicated headers you no longer
have control over the actually required headers for that particular
source file.
I still do not get it. pch.h has only headers that are needed for
every source
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > Feels that some intrusiveness is required to make this work...
| > We should try hard to avoid that.
| >
|
| According to the link I sent to you, the best solution, as far as I know, is
|
| 1. make pch.h contains commonly used header files
| 2. include p
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > | stdafx.h contains all commonly used headers. msvc knows from a
| > | compiler flag (or by default) that stdafx.h (stopping header) is
| > | pre-processed and skip it.
| >
| > Use #pragma hdrstop instead.
|
| We do not have this in .C either.
This would
Feels that some intrusiveness is required to make this work...
We should try hard to avoid that.
According to the link I sent to you, the best solution, as far as I know, is
1. make pch.h contains commonly used header files
2. include pch.h in all source files
3. have a pch.cpp with #include p
| That is what I meant. our pch.h contains headers that are not commonly
| used. (and in pch mode, they are included.)
Then they should be regenerated/reviewed.
I actually only looked at src/mathed/pch.h. But if pch.h indeed has
headers that are commonly included, why not include it and remove
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| I need good examples to understand this properly.
|
|
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_PREDIR_hdrstop.asp
|
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.yc.a
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > some sourcefiles will get includes
| > they strictly speaking did not need.
|
| That is what I meant. our pch.h contains headers that are not commonly
| used. (and in pch mode, they are included.)
Then they should be regenerated/reviewed.
| > | In pch m
some sourcefiles will get includes
they strictly speaking did not need.
That is what I meant. our pch.h contains headers that are not commonly
used. (and in pch mode, they are included.)
| In pch mode,
| --include=pch.h is passed. This will *not* work with msvc since msvc
| scans source file f
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > and how will that change if you include pch.h in all the source files,
| > excepti being overly intrusive? or having some files compiled iwth pch
| > and some not...=?
|
| I do not think this is a matter of intrusiveness.
| By definition, PCH separates
and how will that change if you include pch.h in all the source files,
excepti being overly intrusive? or having some files compiled iwth pch
and some not...=?
I do not think this is a matter of intrusiveness.
By definition, PCH separates commonly used headers from all source
files, compile the
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > Does it make sense to sdd #include ?
|
| I do not understand why we do not add pch.h in all source files, and
| include pch.h only with pch=yes. I notice that, for example,
| src/mathed/pch.h does not really hold headers that all source files
| will use s
"Bo Peng" <[EMAIL PROTECTED]> writes:
| Dear all,
|
| I am also looking at msvc pch. I find that our source code does not
| really conform with the convention. Usually, we should have
|
| 1. pch.h (we have)
| 2. pch.cpp with
|#include
why?
| 3. every source file
| #include
no. (pch sh
Does it make sense to sdd #include ?
I do not understand why we do not add pch.h in all source files, and
include pch.h only with pch=yes. I notice that, for example,
src/mathed/pch.h does not really hold headers that all source files
will use so adding #include pch.h means unnecessary burden to
Dear all,
I am also looking at msvc pch. I find that our source code does not
really conform with the convention. Usually, we should have
1. pch.h (we have)
2. pch.cpp with
#include
3. every source file
#include
Then, pch.cpp is compiled to get pch.pch, and pch.pch will be used for
other s
Dear all,
I am trying to implement pch for scons under linux. But get some funny
results. Using src/mathed as an example, make file (pch on) takes 87s,
scons (pch off) takes 89s, and scons (pch on) takes 102s. Maybe
src/mathed is not a good example, but
1. Has anyone seriously tested the perform
53 matches
Mail list logo
