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

[Libreoffice] feature/gnumake4

[Matúš Kukan]

Hi all,

I have some questions about feature/gnumake4 branch.
It can now start. I'm sending two more patches. First needs review,
the second should be good but I did not push that either.
There was some issue with creating ..Env.Set.sh.

What's the plan with that branch? Just to merge and then delete?
I was trying to merge bootstrap and base.
I've done my best I think but there was some error with set_soenv
(first patch) and then something with Library makefiles. It can't
register components or something like that after my attempt of merge.
I don't know how to solve that and I'm not the right person because I
was not working in that area in any of the branches.
It was hard to merge bootstrap because especially in RepositoryFixes
there were many commits in both branches and now they differ too much.

And about the base. 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.
Each library needs its own precompiled header file? Because in base
(gnumake4) there were created new headers and source files changed to
include the right header and now is hard to know if there were also
some other changes or not. It's not finished because in Library_foo
makefile is still old common precompiled header. But that's just
detail.

Personally I'd prefer just to get from that branch what I want instead
of true merging. That way you don't have to be so careful because for
example there are often restored removed files by merge.

Maybe I could merge some modules (but probably with help like in base
I'm not sure if we want that change). I did not look at all, so I'm
not sure.
But at least bootstrap has to merge someone else.

All the best,
Matus
From 6f51b02a7543a4a0ae8f76d902cc87970bc6a1f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mat=C3=BA=C5=A1=20Kukan?= matus.ku...@gmail.com
Date: Fri, 15 Jul 2011 00:15:32 +0200
Subject: [PATCH] Revert some changes in set_soenv.in

This partially reverts commit 3ad912abd7c2106c4ba6cd35e2ead954759d5cc8
---
 set_soenv.in |   26 ++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/set_soenv.in b/set_soenv.in
index 87ecc76..2a2b975 100755
--- a/set_soenv.in
+++ b/set_soenv.in
@@ -1470,6 +1470,8 @@ $nmake   = 'dmake';
 # VI. Open the output file.
 #--
 #
+open( OUT, $outfile ) ||
+   die Cannot open $outfile: $!\n;
 
 #
 #--
@@ -2075,6 +2077,8 @@ ToFile( ZIPDEP,zipdep.pl,  e );
 #
 # Writing the aliases to file.
 ToFile( Aliases.,  $empty, c );
+ToFile( Don't set aliases when bootstrapping, $empty, c );
+ToFile( if test -z \\$_ISBOOTSTRAP_\; then, $empty, z);
 
 ToFile( alias mkout,   $mkout, a );
 ToFile( alias deliver, $deliver,   a );
@@ -2085,6 +2089,17 @@ if ( $platform !~ m/cygwin/ )
 {  ToFile( alias nmake,   $nmake, a );
 }
 
+ToFile( fi,$empty, z);
+
+# Check if the right dmake version is used. (W32 only)
+if ( $platform =~ m/cygwin/ ) {
+ToFile( Check if the right dmake version is used., $empty, c );
+# Invalidate build environment.
+ToFile( WORK_STAMP, _invalid_, e );
+# Restore valid environment if test was successful.
+ToFile( WORK_STAMP,$WORK_STAMP,e );
+ToFile( , $empty, n);
+}
 
 # on Solaris, MacOSX and FreeBSD, set GNUCOPY and GNUPATCH
 if ($platform =~ m/solaris|darwin|freebsd/)
@@ -2106,6 +2121,8 @@ print OUT unset $unsetvars$newline;
 # VIII. Closing output file.
 #---
 #
+close( OUT ) || print Can't close $outfile: $!;
+
 #
 #--
 # IX. Sourcing the output file.
@@ -2151,6 +2168,8 @@ $bootfile = bootstrap;
 open( OUT, $bootfile ) ||
 die Cannot open $bootfile: $!\n;
 print OUT #!/bin/sh\n;
+print OUT _ISBOOTSTRAP_=TRUE ; export _ISBOOTSTRAP_ ; . $SRC_ROOT/$outfile\n;
+print OUT unset _ISBOOTSTRAP_; export _ISBOOTSTRAP_\n;
 if ( $MINGW eq yes )
 {  print OUT 'PATH=/usr/bin:$PATH : export PATH'.\n; }
 close( OUT ) || print Can't close $bootfile: $!;
@@ -2264,6 +2283,7 @@ sub ToFile {
  $envvar =~ s/\\//g;
 
  printf(%-12s %-17s %-10s %s\n, The variable, $_[ 0 ], is set to:, $envvar) if ( '@VERBOSE@' eq 'TRUE' );
+ print OUT $_[ 0 ]=\$envvar\$newline;  # to sh file
  $exportvars .=  $_[ 0 ];# add to export list for sh file
 
   } else {
@@ -2274,6 +2294,7 @@ sub ToFile {
elsif ( $_[ 2 ] eq a )
{  # Write an alias to file.
   print The $_[ 0 ] is set to: $_[ 1 ]\n if ( '@VERBOSE@' eq 'TRUE' );# to stdout
+  print OUT $_[ 0 ]=$_[ 1 ]$newline;  # to sh file
}
elsif ( $_[ 2 ] eq c )
{  # Write a comment to file.
@@ -2284,9 +2305,14 @@ sub ToFile {
  print $comment $_[ 0 ]$newline;
  print $comment$newline;
   }
+  print OUT $newline;
+  print OUT