Re: Has the time come to get rid of the "delivering" of public headers?

Bjoern Michaelsen <bjoern.michaelsen -AT- canonical.com>
Thu, 23 Feb 2012 01:31:54 +0100

On Wed, Feb 22, 2012 at 03:09:49PM +0100, Lubos Lunak wrote:

 Could not the windows build be helped by having only one location for include 
files where a script would at the beginning of the build create for each .hxx 
file a small wrapper with the same name only doing #include of the real one, 
with the right path to it?


An _additional_ file to open? I highly doubt it will increase windows
performance. I would assume the opposite, but of course, I am open to hard
facts.


 And, since I'm already asking, is the Windows performance the reason include 
files are scattered this way? E.g. in sw/ I find this actually rather 
annoying, some .hxx files are in inc/, some next to .cxx sources, Writer 
AFAIK does not really export anything anyway, and I always have to jump 
around just to find the right header file :(.


No its just historic mess. Never attribute to malice ...

Best,

Bjoern

Context

Re: Has the time come to get rid of the "delivering" of public headers? (continued)
- Re: Has the time come to get rid of the "delivering" of public headers? · Eike Rathke
  - Re: Has the time come to get rid of the "delivering" of public headers? · Noel Grandin
    - Re: Has the time come to get rid of the "delivering" of public headers? · Tor Lillqvist
      - Re: Has the time come to get rid of the "delivering" of public headers? · Michael Stahl

Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.