[Libreoffice] [PATCH] Fix fdo#42783 get rid of CPU define/build system variable

[Norbert Thiebaud]

On Tue, Dec 20, 2011 at 2:52 AM, Victor Lee <konya.vic at gmail.com> wrote:

First welcome to LibreOffice...

> This patch substituts $CPU to $CPUNAME in makfiles and has been
> successfully built on my Linux/x86 machine.
>  However, there are two
> questions remain:
> 1) Statements setting $CPU="U" (looks like it should be "SPARC64")
> could not be found in set_soenv.in or related files, but $(CPU)=="U"
> is checked in some makefiles.  I left those lines untouched in this
> patch.
> 2) Fixing patch files directly (e.g., jpeg/jpeg-6b.patch) seems not a
> good idea, though I have done it.
> Please give me your advice.


thee are more little problems...

a/
 if ( "@WITH_MOZILLA@" eq "YES" and "@BUILD_MOZAB@" ne "TRUE" and
"@SYSTEM_MOZILLA@" ne "YES" )
 {
    print("Checking for prebuilt Mozilla libraries ...");
    my $mozbinfile = $SRC_ROOT."/moz/zipped/";
-   $mozbinfile .= $OS.$COM.$CPU;
+   $mozbinfile .= $OS.$COM.$CPUNAME;
    if ( -e $mozbinfile."inc.zip"

These filename have not actually changed. they are hosted in our web
site and we can't ust 'rename' them or we would break 3.4/3.5 and any
version prior to the patch

b/ INPATH adn OUPATH have a name that is today constructed based on
CPU... removing that 1 letter shortcut from the rest of the product
will render these naming convention even more opaque.

c/ most if not all these use of CPU are in dmake module, which are
destined to be converted to gbuild... so I suspect a lot of these
'uses' will disappear during the conversion.

d/
--- a/libpng/libpng-1.5.1.patch
+++ b/libpng/libpng-1.5.1.patch
@@ -21,7 +21,7 @@
 +.INCLUDE :  settings.mk
 +
 +
-+.IF "$(GUI)$(CPU)"=="WNTP"
++.IF "$(GUI)$(CPUNAME)"=="WNTPOWERPC" || "$(GUI)$(CPUNAME)"=="WNTPOWERPC64"
 +CFLAGS=$(CFLAGS) -Od
 +.ENDIF
 +

illustrate that things do not necessarily get 'simplified'.

e/ there are missed occurrences, like in hyphen, lpsolve, redland...
for instance. you can't remove the setup in set_soenv.in until _all_
use case have been removed.
so maybe first patching out the use cases -- starting with the one
that are straight forward and fo not have side effect --  and then...
a final patch that clean-up set_soenv.in once we are sure there is
nothing left.

I'm really sorry I did not see that fdo#42783 earlier, I would have
added these remarks earlier... _before_ you did the work :-/

But the bug was filled by Bjorn, so I'll let him weight in...

Norbert