Re: [Libreoffice] feature/gnumake4

[Tor Lillqvist]

 I've done my best I think but there was some error with set_soenv
 (first patch) 

Hmm, I looked at the first patch, and I definitely don't think we should 
re-introduce some Hamburg-specific stuff that we don't understand, want or 
need. Not even OOo at Apache will (once they have something they can start 
trying to build) need those _ISBOOTSTRAP, WORK_STAMP etc things. All that (for 
instance, maybe half (?) of build.pl) is double-plus-obsolete.

 There were some changes with precompiled headers.
 But that's not finished. Are they useful for something. I don't
 understand what that should do and have not asked yet.

In theory, pre-compiled headers are quite useful for Windows compilations, they 
are said to speed up the build significantly.

In practice, successfully being able to use pre-compiled headers requires 
awareness of it and carefulness and following correct (documented somewhere in 
the OOo wiki, hopefully) procedure while coding, and we certainly have not had 
any of that. I once tried to use pre-compiled headers when building on Windows, 
I had to fix lots of stuff here and there in one module, and in another it was 
just hopeless, so I gave up. I wonder if even Hamburg actually used 
pre-compiled headers in their Windows builds?

I now think that we should just not bother even trying. A key to success is 
recognizing your limitations.

Of course, the above is just my personal opinion, more clever people might 
disagree.

--tml


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] feature/gnumake4

[Bjoern Michaelsen]

Hi Matúš, Hi Tor,

On Mon, 18 Jul 2011 00:32:49 -0600
Tor Lillqvist tlillqv...@novell.com
wrote:

 Hmm, I looked at the first patch, and I definitely don't think we
 should re-introduce some Hamburg-specific stuff that we don't
 understand, want or need. Not even OOo at Apache will (once they have
 something they can start trying to build) need those _ISBOOTSTRAP,
 WORK_STAMP etc things. All that (for instance, maybe half (?) of
 build.pl) is double-plus-obsolete.

Right, but just getting it to build instead of having two half
complete conflicting removals of tcsh in the branch is a value of its
own. ;) 

 In theory, pre-compiled headers are quite useful for Windows
 compilations, they are said to speed up the build significantly.

Yes, they are. A reason for this is also the badnesss of our codebase:
little encapsulation = huge amounts of included headers.
 
 In practice, successfully being able to use pre-compiled headers
 requires awareness of it and carefulness and following correct
 (documented somewhere in the OOo wiki, hopefully) procedure while
 coding, and we certainly have not had any of that.

Well, IIRC there are two major issues with precompiled headers:
- tooltypes vs. windows native types, however this problem should be
  limited to vcl only mostly after the removetooltypes integration
- other namespace conflicts introduced by using namespace statements,
  the most obnoxious being ::rtl::Reference
  and ::com::sun::star::uno::Reference conflicts. If somebody uses
  using namespace ::rtl; using namespace ::com::sun::star::uno; in a
  cxx because he 'knows' only one of the Reference declarations will
  get included, thats trouble already by itself. The risk of this
  blowing up in your face is of course greatly increased by precompiled
  headers. There is also a related EasyHack still:
  
http://wiki.documentfoundation.org/Development/Easy_Hacks_Complete_List#Remove_.22using_namespace_::rtl.22

 I once tried to use pre-compiled headers when building on Windows, I
 had to fix lots of stuff here and there in one module, and in another
 it was just hopeless, so I gave up. I wonder if even Hamburg actually
 used pre-compiled headers in their Windows builds?

It was used on all builds and tinderboxes, which is the only way to
make that happen. 

 I now think that we should just not bother even trying. A key to
 success is recognizing your limitations.

With the majority of our devs working on *nix, I agree. Instead of
spending time get this fragile one platform feature (on gcc it is
totally not worth it) working, we should try to fix the root cause, by
improving encapsulation (e.g. get to the point where not ~400 .cxx in
sw include doc.hxx, which itself includes half of the all the other
headers in office).

Of course, thats a nut that is a bit harder to crack -- but it will
improve so much more than windows build times.

Best,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice