On Sun, Nov 08, 2009 at 11:19:55AM +0800, John McCabe-Dansted wrote:
> I have heard that some .h files include other .h files, but are not
> required to do so by POSIX etc. Thus removing them may harm
> portability.
This discussion is not much about C headers. They are comparatively
short and abov
On Sun, Nov 08, 2009 at 12:55:15AM +0100, Vincent van Ravesteijn wrote:
> Pavel Sanda schreef:
>> Vincent van Ravesteijn wrote:
>>
my draft implied one compilation per one #include in our sources, no
combinations. the only tweaking part was that detection in .h files
- one has
>>
On Sat, Nov 07, 2009 at 11:12:06PM +0100, Alex Fernandez wrote:
> On Sat, Nov 7, 2009 at 8:19 PM, Steve Litt wrote:
> > I'm wondering if there's a less compute intensive method than the brute
> > force
> > method of removing a #include from a .h, and then recompiling every .cpp
> > file.
>
> I
On Saturday 07 November 2009 13:37:30 Pavel Sanda wrote:
> hi,
>
> if there is somebody who would like to contribute to lyx and like to tackle
> with some python/bash scripting, consider fixing the bug
> http://www.lyx.org/trac/ticket/6305 .
>
> pavel
Angus has tackled this task years ago. Som
John McCabe-Dansted wrote:
> I have heard that some .h files include other .h files, but are not
> required to do so by POSIX etc. Thus removing them may harm
> portability. I am not sure how this could be detected automatically
we have to be careful about few headers like cstdlib. then i remember
November 2009 19:19
To: LyX devel
Subject: Re: Scripting fun - removing unneeded headers from source code
On Saturday 07 November 2009 08:37:30 Pavel Sanda wrote:
> hi,
>
> if there is somebody who would like to contribute to lyx and like to tackle
> with some python/bash scripti
I have heard that some .h files include other .h files, but are not
required to do so by POSIX etc. Thus removing them may harm
portability. I am not sure how this could be detected automatically
That said I don't know much about this. And even if this is a problem,
it presumably would help to kno
Pavel Sanda wrote:
> Vincent van Ravesteijn wrote:
> > I think you'll mostly remove includes that are redundant in some sense.
> > It's less likely there are huge amounts of costly includes.
>
> who knows. i believe that those 13 includes i removed from insetmathhull
> today were not just redunda
On Sat, Nov 7, 2009 at 11:12 PM, Alex Fernandez wrote:
> I thought about semantic processing: read all the prototypes in the
> .h, then see if they are actually used in the .cpp files. Remove those
> which aren't and try compiling; if the job has been well done then
> compilation should proceed wi
Vincent van Ravesteijn wrote:
> I think you'll mostly remove includes that are redundant in some sense.
> It's less likely there are huge amounts of costly includes.
who knows. i believe that those 13 includes i removed from insetmathhull
today were not just redundant of other headers.
pavel
Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
my draft implied one compilation per one #include in our sources, no
combinations. the only tweaking part was that detection in .h files - one
has
to distinguish whether the compilation fails because of header
insuficiency in
.h or in cons
Vincent van Ravesteijn wrote:
>> my draft implied one compilation per one #include in our sources, no
>> combinations. the only tweaking part was that detection in .h files - one
>> has
>> to distinguish whether the compilation fails because of header
>> insuficiency in
>> .h or in consequent .cp
Pavel Sanda schreef:
Steve Litt wrote:
The part where you remove .h includes from .cpp is dead bang easy if rather
slow. Not so with the .h includes inside other .h files. For each #include
removal from a .h file, you'd have to compile every .cpp that includes the
including .h.
my d
Steve Litt wrote:
> The part where you remove .h includes from .cpp is dead bang easy if rather
> slow. Not so with the .h includes inside other .h files. For each #include
> removal from a .h file, you'd have to compile every .cpp that includes the
> including .h.
my draft implied one compila
On Sat, Nov 7, 2009 at 8:19 PM, Steve Litt wrote:
> I'm wondering if there's a less compute intensive method than the brute force
> method of removing a #include from a .h, and then recompiling every .cpp file.
I thought about semantic processing: read all the prototypes in the
.h, then see if th
On Saturday 07 November 2009 08:37:30 Pavel Sanda wrote:
> hi,
>
> if there is somebody who would like to contribute to lyx and like to tackle
> with some python/bash scripting, consider fixing the bug
> http://www.lyx.org/trac/ticket/6305 .
>
> pavel
Hi Pavel,
The part where you remove .h inclu
hi,
if there is somebody who would like to contribute to lyx and like to tackle
with some
python/bash scripting, consider fixing the bug
http://www.lyx.org/trac/ticket/6305 .
pavel
17 matches
Mail list logo
