Re: Updating the build guide (Re: a more sane way to override optimization flags in gbuild)

[Kay Schenk]

On 12/03/2017 12:30 PM, Jim Jagielski wrote:

On Dec 3, 2017, at 1:31 PM, Andrea Pescetti  wrote:

Keith N. McKenna wrote:

That begs the Question should we add a section to the overall build
guide for CentOS6? If yes I can add the section as a clone of the
CentOS5 Guide with all the proper warnings and notes about it needing
updating for the CentOS6 specifics.

No, this wouldn't be helpful since the CentOS 6 guide should be almost 
completely different from the CentOS 5 one (that section is meant to only 
contain the distribution-specific details, and they differ significantly 
between major versions of the same distribution). So this is best done by 
someone who actually did build on CentOS 6.


Actually, as someone who has built on both, the instructions are
pretty much mirrors. In fact, a simple s/5/6/p almost does it :)


Ditto for me. I've been building on CentOS6 (32 bit) for at least a year 
and really no major issues. I've never built on CentOS 5 so I can't say 
what the differences might be.


My plan is to edit 
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step 

and make the CentOS5 section AOO 4.1.x specific and, similar to what
I did with the macOS guide, create a new CentOS6 section for 4.2.x and
later.




--
--
MzK

"Don't you know that it's worth
 every treasure on earth
 To be young at heart."
  -- song, "Young at Heart"


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Updating the build guide (Re: a more sane way to override optimization flags in gbuild)

[Keith N. McKenna]

On 12/3/2017 3:30 PM, Jim Jagielski wrote:
> 
>> On Dec 3, 2017, at 1:31 PM, Andrea Pescetti  wrote:
>>
>> Keith N. McKenna wrote:
>>> That begs the Question should we add a section to the overall build
>>> guide for CentOS6? If yes I can add the section as a clone of the
>>> CentOS5 Guide with all the proper warnings and notes about it needing
>>> updating for the CentOS6 specifics.
>>
>> No, this wouldn't be helpful since the CentOS 6 guide should be almost 
>> completely different from the CentOS 5 one (that section is meant to only 
>> contain the distribution-specific details, and they differ significantly 
>> between major versions of the same distribution). So this is best done by 
>> someone who actually did build on CentOS 6.
>>
> 
> Actually, as someone who has built on both, the instructions are
> pretty much mirrors. In fact, a simple s/5/6/p almost does it :)
> 
> My plan is to edit 
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step
>  
> 
> and make the CentOS5 section AOO 4.1.x specific and, similar to what
> I did with the macOS guide, create a new CentOS6 section for 4.2.x and
> later.
> 
> 
Jim;
I am not a Linux user, but I am very familiar with the mwiki. Any help I
can be all you have to do is ask.

Regards
Keith




signature.asc
Description: OpenPGP digital signature

Re: Updating the build guide (Re: a more sane way to override optimization flags in gbuild)

[Jim Jagielski]

> On Dec 3, 2017, at 1:31 PM, Andrea Pescetti  wrote:
> 
> Keith N. McKenna wrote:
>> That begs the Question should we add a section to the overall build
>> guide for CentOS6? If yes I can add the section as a clone of the
>> CentOS5 Guide with all the proper warnings and notes about it needing
>> updating for the CentOS6 specifics.
> 
> No, this wouldn't be helpful since the CentOS 6 guide should be almost 
> completely different from the CentOS 5 one (that section is meant to only 
> contain the distribution-specific details, and they differ significantly 
> between major versions of the same distribution). So this is best done by 
> someone who actually did build on CentOS 6.
> 

Actually, as someone who has built on both, the instructions are
pretty much mirrors. In fact, a simple s/5/6/p almost does it :)

My plan is to edit 
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step 

and make the CentOS5 section AOO 4.1.x specific and, similar to what
I did with the macOS guide, create a new CentOS6 section for 4.2.x and
later.

Updating the build guide (Re: a more sane way to override optimization flags in gbuild)

[Andrea Pescetti]

Keith N. McKenna wrote:

That begs the Question should we add a section to the overall build
guide for CentOS6? If yes I can add the section as a clone of the
CentOS5 Guide with all the proper warnings and notes about it needing
updating for the CentOS6 specifics.


No, this wouldn't be helpful since the CentOS 6 guide should be almost 
completely different from the CentOS 5 one (that section is meant to 
only contain the distribution-specific details, and they differ 
significantly between major versions of the same distribution). So this 
is best done by someone who actually did build on CentOS 6.



Also will the top level build guide at
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO need
updating?


Not major changes at least. It might need some minor updates, but the 
process didn't change much. Still, since we do not provide a detailed 
README with build instructions in the sources, it will be important to 
make sure the page still applies when we are closer to a release. Thanks 
for the heads-up.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Keith N. McKenna]

On 12/3/2017 4:14 AM, Andrea Pescetti wrote:
> Jim Jagielski wrote:
>>> On Dec 2, 2017, at 5:56 PM, Andrea Pescetti wrote:
>>> On 30/11/2017 Jim Jagielski wrote:
 I think for 4.2.x and later, we have deprecated CentOS5 as a supported
 build system... I ran into a LOT of issues.
>>> Such as, for example?
>> for starters:
>>    o zip 3.0.
>>    o GIO
> 
> OK, I now get it. You ran into issues when you tried to build *trunk* on
> CentOS 5, not when you built 4.1.4 on CentOS 5. I had read your sentence
> above as "We should deprecate CentOS 5 since I found lots of issues
> [when building 4.1.4]".
> 
>> Isn't that exactly what I'm doing???
> 
> Yes, we are on the same page:
> 
> - The CentOS 5 guide works well and smoothly for 4.1.x
> 
> - The CentOS 5 guide does not work any longer for trunk (for the reasons
> Damjan detailed), but this is irrelevant as we'll update to CentOS 6
> anyway.
> 
> Regards,
>   Andrea.
That begs the Question should we add a section to the overall build
guide for CentOS6? If yes I can add the section as a clone of the
CentOS5 Guide with all the proper warnings and notes about it needing
updating for the CentOS6 specifics.

Also will the top level build guide at
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO need
updating?

Regards
Keith



signature.asc
Description: OpenPGP digital signature

Re: a more sane way to override optimization flags in gbuild

[Andrea Pescetti]

Jim Jagielski wrote:

On Dec 2, 2017, at 5:56 PM, Andrea Pescetti wrote:
On 30/11/2017 Jim Jagielski wrote:

I think for 4.2.x and later, we have deprecated CentOS5 as a supported
build system... I ran into a LOT of issues.

Such as, for example?

for starters:
   o zip 3.0.
   o GIO


OK, I now get it. You ran into issues when you tried to build *trunk* on 
CentOS 5, not when you built 4.1.4 on CentOS 5. I had read your sentence 
above as "We should deprecate CentOS 5 since I found lots of issues 
[when building 4.1.4]".



Isn't that exactly what I'm doing???


Yes, we are on the same page:

- The CentOS 5 guide works well and smoothly for 4.1.x

- The CentOS 5 guide does not work any longer for trunk (for the reasons 
Damjan detailed), but this is irrelevant as we'll update to CentOS 6 anyway.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Damjan Jovanovic]

On Sun, Dec 3, 2017 at 2:25 AM, Jim Jagielski  wrote:

>
> > On Dec 2, 2017, at 5:56 PM, Andrea Pescetti  wrote:
> >
> > On 30/11/2017 Jim Jagielski wrote:
> >> I think for 4.2.x and later, we have deprecated CentOS5 as a supported
> >> build system... I ran into a LOT of issues.
> >
> > Such as, for example?
>
> for starters:
>   o zip 3.0.
>   o GIO
>
>
If you *really* need GIO, try adding --disable-gio --enable-gnome-vfs to
./configure.

The check for ZIP version 3.0 was added in revision 1755455, the gbuild
branch merge into trunk. Within that branch it was added in this commit:

r1409544 | arist | 2012-11-15 01:22:40 +0200 (Thu, 15 Nov 2012) | 9 lines
Changed paths:
   M /incubator/ooo/branches/gbuild/main/configure.in

gnumake4_047_ce56f9735b9c.patch
# HG changeset patch
# User Michael Stahl 
# Date 1301690824 0
# Node ID ce56f9735b9cd04f4e2724754fe7c11d9cec1ca9
# Parent  e37d17b6d8d93e87a4886268f338a2d4ea2a6304
gnumake4: configure.in: require Info-ZIP 3.0


apparently around the time they were adding support for Java in gbuild.
Maybe gbuild uses a ZIP 3 feature for JAR files? This is all we do with zip
in gbuild:

$(gb_Zip_ZIPCOMMAND) -rX -FS $(call gb_Zip_get_target,$*) $(FILES) )

are -rX or -FS new?

But can we please use another thread for such issues?

Damjan

Re: a more sane way to override optimization flags in gbuild

[Jim Jagielski]

> On Dec 2, 2017, at 5:56 PM, Andrea Pescetti  wrote:
> 
> On 30/11/2017 Jim Jagielski wrote:
>> I think for 4.2.x and later, we have deprecated CentOS5 as a supported
>> build system... I ran into a LOT of issues.
> 
> Such as, for example?

for starters:
  o zip 3.0.
  o GIO

>  I think that the guide we have at
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_5
> used to be the most solid procedure to build OpenOffice, while it is 
> well-known that building on Windows is complex and building on Mac is even 
> more complex and resulted in broken builds several times.
> 
> The reason I'm asking is not because CentOS 5 is particularly relevant (I 
> think we have agreement that we'll switch to CentOS 6 for 4.2.x and that the 
> next, if any, 4.1.x releases will cover major regressions only), but because 
> I think that an updated version (to CentOS 6) of that guide should be the 
> reference for our 4.2.x builds. So if there are issues that can be ironed 
> out, better to do it as soon as possible.

Isn't that exactly what I'm doing??? Or do you have some
other point to make?

Re: a more sane way to override optimization flags in gbuild

[Andrea Pescetti]

On 30/11/2017 Jim Jagielski wrote:

I think for 4.2.x and later, we have deprecated CentOS5 as a supported
build system... I ran into a LOT of issues.


Such as, for example? I think that the guide we have at
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_5
used to be the most solid procedure to build OpenOffice, while it is 
well-known that building on Windows is complex and building on Mac is 
even more complex and resulted in broken builds several times.


The reason I'm asking is not because CentOS 5 is particularly relevant 
(I think we have agreement that we'll switch to CentOS 6 for 4.2.x and 
that the next, if any, 4.1.x releases will cover major regressions 
only), but because I think that an updated version (to CentOS 6) of that 
guide should be the reference for our 4.2.x builds. So if there are 
issues that can be ironed out, better to do it as soon as possible.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Peter Kovacs]

On 30.11.2017 20:44, Don Lewis wrote:

On 30 Nov, Jim Jagielski wrote:

I think for 4.2.x and later, we have deprecated CentOS5 as a supported
build system... I ran into a LOT of issues. So, imo, any fix that is
*specific* for CentOS5 should be discounted.

I can't even do CentOS5 builds anymore.  My CentOS5 VM broke and CentOS
moved the package location so yum doesn't work anymore.

There is a lot of old baggage around, like undocumented workarounds for
even more ancient compilers and support for platforms that we don't
support anymore.  Do we want to spend a lot of time actively yanking
that stuff out?
Or even Code has been extended without touching the old code, in order 
to minimize bugs.

Yea, I would opt for improving maintenance Quality whenever possible.
But we can do that as we move along with bugfixing and enhancement.
Even if the maintenance quality is only improved by a bit it will help 
in the long run.


The architectural change Damjan did in the db interface was imho a good 
move.

For 4.1.x, I'd prefer something which is a quick and easy fix,
rather than something that touches a lot of build system moving
parts.

I wouldn't want to backport the gbuild changes to 4.1.x.  I see this as
a trunk-only improvement to ease future maintenance.

+1

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Don Lewis]

On 30 Nov, Jim Jagielski wrote:
> I think for 4.2.x and later, we have deprecated CentOS5 as a supported
> build system... I ran into a LOT of issues. So, imo, any fix that is
> *specific* for CentOS5 should be discounted.

I can't even do CentOS5 builds anymore.  My CentOS5 VM broke and CentOS
moved the package location so yum doesn't work anymore.

There is a lot of old baggage around, like undocumented workarounds for
even more ancient compilers and support for platforms that we don't
support anymore.  Do we want to spend a lot of time actively yanking
that stuff out?
 
> For 4.1.x, I'd prefer something which is a quick and easy fix,
> rather than something that touches a lot of build system moving
> parts.

I wouldn't want to backport the gbuild changes to 4.1.x.  I see this as
a trunk-only improvement to ease future maintenance.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Patricia Shanahan]

I would put it a bit more strongly. I think 4.1.x should be strictly 
reserved for changes that are essential to fix urgent user-visible bugs.


On 11/30/2017 5:59 AM, Jim Jagielski wrote:

I think for 4.2.x and later, we have deprecated CentOS5 as a supported
build system... I ran into a LOT of issues. So, imo, any fix that is
*specific* for CentOS5 should be discounted.

For 4.1.x, I'd prefer something which is a quick and easy fix,
rather than something that touches a lot of build system moving
parts.


On Nov 30, 2017, at 1:47 AM, Don Lewis  wrote:

On 30 Nov, Peter kovacs wrote:

The bug mentioned is referring to a gcc bug in 4.2.x. The bugtrackerlink claims 
it is fixed in 4.3.x
Do we need to keep these workarounds?
Maybe we can drop this all together. Would raise maintainability in general.
Who uses 4.2.x compilers?


RHEL / CentOS 5 uses 4.1.x.  RHEL / CentOS 6 uses 4.4.x.  Versions of
FreeBSD without clang use 4.2.1 as the system compiler, but the FreeBSD
port brought in a newer version of GCC in that case.

There are a whole bunch of these compiler bug workarounds in the
makefiles, and many of them are not well documented.  It would be nice
to yank them out, but that would require a lot of testing so that we
don't revive old bugs.

The dmake build has $(CCNUMVER), which encodes the compiler version so
that it is able to enable these workarounds when building with a broken
compiler.  Unfortunately, $(CCNUMVER) is not available on the gbuild
side.  That's why the FreeBSD port includes a whole bunch of patches
that I haven't upstreamed. The FreeBSD port is able to conditionally
apply the patches when it detects it is using certain compiler versions.

This new optimization override mechanism should make maintenance easier
since it only requires making a change to the .mk file in one place. The
old method requires two sets of edits per workaround.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



---
This email has been checked for viruses by AVG.
http://www.avg.com


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Jim Jagielski]

I think for 4.2.x and later, we have deprecated CentOS5 as a supported
build system... I ran into a LOT of issues. So, imo, any fix that is
*specific* for CentOS5 should be discounted.

For 4.1.x, I'd prefer something which is a quick and easy fix,
rather than something that touches a lot of build system moving
parts.

> On Nov 30, 2017, at 1:47 AM, Don Lewis  wrote:
> 
> On 30 Nov, Peter kovacs wrote:
>> The bug mentioned is referring to a gcc bug in 4.2.x. The bugtrackerlink 
>> claims it is fixed in 4.3.x
>> Do we need to keep these workarounds?
>> Maybe we can drop this all together. Would raise maintainability in general.
>> Who uses 4.2.x compilers?
> 
> RHEL / CentOS 5 uses 4.1.x.  RHEL / CentOS 6 uses 4.4.x.  Versions of
> FreeBSD without clang use 4.2.1 as the system compiler, but the FreeBSD
> port brought in a newer version of GCC in that case.
> 
> There are a whole bunch of these compiler bug workarounds in the
> makefiles, and many of them are not well documented.  It would be nice
> to yank them out, but that would require a lot of testing so that we
> don't revive old bugs.
> 
> The dmake build has $(CCNUMVER), which encodes the compiler version so
> that it is able to enable these workarounds when building with a broken
> compiler.  Unfortunately, $(CCNUMVER) is not available on the gbuild
> side.  That's why the FreeBSD port includes a whole bunch of patches
> that I haven't upstreamed. The FreeBSD port is able to conditionally
> apply the patches when it detects it is using certain compiler versions.
> 
> This new optimization override mechanism should make maintenance easier
> since it only requires making a change to the .mk file in one place. The
> old method requires two sets of edits per workaround.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Don Lewis]

On 30 Nov, Peter kovacs wrote:
> The bug mentioned is referring to a gcc bug in 4.2.x. The bugtrackerlink 
> claims it is fixed in 4.3.x
> Do we need to keep these workarounds?
> Maybe we can drop this all together. Would raise maintainability in general.
> Who uses 4.2.x compilers?

RHEL / CentOS 5 uses 4.1.x.  RHEL / CentOS 6 uses 4.4.x.  Versions of
FreeBSD without clang use 4.2.1 as the system compiler, but the FreeBSD
port brought in a newer version of GCC in that case.

There are a whole bunch of these compiler bug workarounds in the
makefiles, and many of them are not well documented.  It would be nice
to yank them out, but that would require a lot of testing so that we
don't revive old bugs.

The dmake build has $(CCNUMVER), which encodes the compiler version so
that it is able to enable these workarounds when building with a broken
compiler.  Unfortunately, $(CCNUMVER) is not available on the gbuild
side.  That's why the FreeBSD port includes a whole bunch of patches
that I haven't upstreamed. The FreeBSD port is able to conditionally
apply the patches when it detects it is using certain compiler versions.

This new optimization override mechanism should make maintenance easier
since it only requires making a change to the .mk file in one place. The
old method requires two sets of edits per workaround.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Peter kovacs]

The bug mentioned is referring to a gcc bug in 4.2.x. The bugtrackerlink claims 
it is fixed in 4.3.x
Do we need to keep these workarounds?
Maybe we can drop this all together. Would raise maintainability in general.
Who uses 4.2.x compilers?

Am 29. November 2017 19:16:29 MEZ schrieb Don Lewis :
>On 29 Nov, Jim Jagielski wrote:
>> I'm just concerned about the CXXFLAGS interaction
>> 
>> The proposed patch breaks how I expect many people
>> are building AOO and it's a regression that, unless
>> we are super clear about it, would bite a lot of
>> people.
>
>How many people set CXXFLAGS in the environment?
>
>Another way to do this is to change the
>gb_LinkTarget_set_*_optimization
>functions to override CXXFLAGS, etc. instead of gb_COMPILEROPTFLAGS.
>That would basically return us to the status quo where the usual way of
>doing per-target overrides to this point has been:
>
># Work around bug in gcc 4.2 / 4.3, see
># http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35182
>ifeq ($(COM),GCC)
>$(eval $(call gb_Library_add_cxxobjects,sc,\
>sc/source/ui/unoobj/chart2uno \
>, $(gb_COMPILERNOOPTFLAGS) $(gb_LinkTarget_EXCEPTIONFLAGS) \
>))
>else
>$(eval $(call gb_Library_add_exception_objects,sc,\
>sc/source/ui/unoobj/chart2uno \
>))
>endif
>
>which manages to lose the debug flags.
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>For additional commands, e-mail: dev-h...@openoffice.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Don Lewis]

On 29 Nov, Jim Jagielski wrote:
> I'm just concerned about the CXXFLAGS interaction
> 
> The proposed patch breaks how I expect many people
> are building AOO and it's a regression that, unless
> we are super clear about it, would bite a lot of
> people.

How about this:

Index: main/framework/Library_fwk.mk
===
--- main/framework/Library_fwk.mk   (revision 1816518)
+++ main/framework/Library_fwk.mk   (working copy)
@@ -61,6 +61,11 @@
$(gb_STDLIBS) \
 ))
 
+# i126622 - Base 4.1.2 does not open Tables and Queries in Mac OSX
+ifeq ($(OS),MACOSX)
+$(call 
gb_LinkTarget_set_cxx_optimization,framework/source/loadenv/loadenv,$(gb_COMPILEROPT1FLAGS))
+endif
+
 $(eval $(call gb_Library_add_exception_objects,fwk,\
framework/source/accelerators/acceleratorcache \
framework/source/accelerators/acceleratorconfiguration \
@@ -190,10 +195,4 @@
framework/source/xml/imagesdocumenthandler \
 ))
 
-# i126622 - Base 4.1.2 does not open Tables and Queries in Mac OSX
-ifeq ($(OS),MACOSX)
-$(call gb_CxxObject_get_target,framework/source/loadenv/loadenv):\
-   T_CXXFLAGS := $(gb_LinkTarget_CXXFLAGS) $(gb_LinkTarget_EXCEPTIONFLAGS) 
$(gb_COMPILERNOOPTFLAGS)
-endif
-
 # vim: set noet sw=4 ts=4:
Index: main/solenv/gbuild/LinkTarget.mk
===
--- main/solenv/gbuild/LinkTarget.mk(revision 1816518)
+++ main/solenv/gbuild/LinkTarget.mk(working copy)
@@ -333,12 +333,12 @@
 $(call gb_LinkTarget_get_clean_target,$(1)) \
 $(call gb_LinkTarget_get_target,$(1)) : GENCXXOBJECTS :=
 $(call gb_LinkTarget_get_headers_target,$(1)) \
-$(call gb_LinkTarget_get_target,$(1)) : T_CFLAGS := $$(gb_LinkTarget_CFLAGS) 
$(CFLAGS)
+$(call gb_LinkTarget_get_target,$(1)) : T_CFLAGS := $$(gb_LinkTarget_CFLAGS)
 $(call gb_LinkTarget_get_headers_target,$(1)) \
 $(call gb_LinkTarget_get_target,$(1)) : T_CXXFLAGS := 
$$(gb_LinkTarget_CXXFLAGS)
 $(call gb_LinkTarget_get_headers_target,$(1)) \
-$(call gb_LinkTarget_get_target,$(1)) : PCH_CXXFLAGS := 
$$(gb_LinkTarget_CXXFLAGS) $(CXXFLAGS)
-$(call gb_LinkTarget_get_target,$(1)) : T_OBJCXXFLAGS := 
$$(gb_LinkTarget_OBJCXXFLAGS) $(OBJCXXFLAGS)
+$(call gb_LinkTarget_get_target,$(1)) : PCH_CXXFLAGS := 
$$(gb_LinkTarget_CXXFLAGS)
+$(call gb_LinkTarget_get_target,$(1)) : T_OBJCXXFLAGS := 
$$(gb_LinkTarget_OBJCXXFLAGS)
 $(call gb_LinkTarget_get_headers_target,$(1)) \
 $(call gb_LinkTarget_get_target,$(1)) : DEFS := $$(gb_LinkTarget_DEFAULTDEFS) 
$(CPPFLAGS)
 $(call gb_LinkTarget_get_headers_target,$(1)) \
@@ -367,10 +367,10 @@
 $(call gb_LinkTarget_get_dep_target,$(1)) : CXXOBJECTS := 
 $(call gb_LinkTarget_get_dep_target,$(1)) : OBJCXXOBJECTS :=
 $(call gb_LinkTarget_get_dep_target,$(1)) : GENCXXOBJECTS :=
-$(call gb_LinkTarget_get_dep_target,$(1)) : T_CFLAGS := 
$$(gb_LinkTarget_CFLAGS) $(CFLAGS)
+$(call gb_LinkTarget_get_dep_target,$(1)) : T_CFLAGS := 
$$(gb_LinkTarget_CFLAGS)
 $(call gb_LinkTarget_get_dep_target,$(1)) : T_CXXFLAGS := 
$$(gb_LinkTarget_CXXFLAGS)
-$(call gb_LinkTarget_get_dep_target,$(1)) : PCH_CXXFLAGS := 
$$(gb_LinkTarget_CXXFLAGS) $(CXXFLAGS)
-$(call gb_LinkTarget_get_dep_target,$(1)) : T_OBJCXXFLAGS := 
$$(gb_LinkTarget_OBJCXXFLAGS) $(OBJCXXFLAGS)
+$(call gb_LinkTarget_get_dep_target,$(1)) : PCH_CXXFLAGS := 
$$(gb_LinkTarget_CXXFLAGS)
+$(call gb_LinkTarget_get_dep_target,$(1)) : T_OBJCXXFLAGS := 
$$(gb_LinkTarget_OBJCXXFLAGS)
 $(call gb_LinkTarget_get_dep_target,$(1)) : DEFS := 
$$(gb_LinkTarget_DEFAULTDEFS) $(CPPFLAGS)
 $(call gb_LinkTarget_get_dep_target,$(1)) : PCH_DEFS := 
$$(gb_LinkTarget_DEFAULTDEFS) $(CPPFLAGS)
 $(call gb_LinkTarget_get_dep_target,$(1)) : INCLUDE := 
$$(gb_LinkTarget_INCLUDE)
@@ -477,9 +477,24 @@
 $(call gb_LinkTarget_get_dep_target,$(1)) : T_OBJCXXFLAGS := $(2)
 endif
 endif
+endef
 
+define gb_LinkTarget_set_c_optimization
+$(call gb_CObject_get_target,$(1)) : CFLAGS := $(filter-out 
$(gb_COMPILEROPTFLAGS),$(CFLAGS)) $(2)
 endef
 
+define gb_LinkTarget_set_cxx_optimization
+$(call gb_CxxObject_get_target,$(1)) : CXXFLAGS := $(filter-out 
$(gb_COMPILEROPTFLAGS),$(CXXFLAGS)) $(2)
+endef
+
+define gb_LinkTarget_set_gencxx_optimization
+$(call gb_GenCxxObject_get_target,$(1)) : CXXFLAGS := $(filter-out 
$(gb_COMPILEROPTFLAGS),$(CXXFLAGS)) $(2)
+endef
+
+define gb_LinkTarget_set_objcxx_optimization
+$(call gb_ObjCxxObject_get_target,$(1)) : OBJCXXFLAGS := $(filter-out 
$(gb_COMPILEROPTFLAGS),$(OBJCXXFLAGS)) $(2)
+endef
+
 define gb_LinkTarget_set_include
 $(call gb_LinkTarget_get_headers_target,$(1)) \
 $(call gb_LinkTarget_get_target,$(1)) : INCLUDE := $(2)
@@ -635,7 +650,7 @@
 
 $(call gb_LinkTarget_get_target,$(1)) : $(call gb_GenCxxObject_get_target,$(2))
 $(call gb_GenCxxObject_get_source,$(2)) : | $(call 
gb_LinkTarget_get_headers_target,$(1))
-$(call gb_GenCxxObject_get_target,$(2)) : T_CXXFLAGS += $(3) $(CXXFLAGS)
+$(call gb_GenCxxObject_get_target,$(2)) : T_CXXFLAGS += $(3)
 
 ifeq 

Re: a more sane way to override optimization flags in gbuild

[Peter kovacs]

+1. I have to adjust build flags in order to reduce my log rubbish at least a 
bit.

Am 29. November 2017 14:54:31 MEZ schrieb Jim Jagielski :
>I'm just concerned about the CXXFLAGS interaction
>
>The proposed patch breaks how I expect many people
>are building AOO and it's a regression that, unless
>we are super clear about it, would bite a lot of
>people.
>
>> On Nov 28, 2017, at 6:13 PM, Don Lewis  wrote:
>> 
>> On 28 Nov, Jim Jagielski wrote:
>>> Wouldn't it make sense to do something like LOCAL_CFLAGS which
>>> could then be manipulated?...
>> 
>> It depends on what the goal is.  What would be nice is if debug flags
>> and optimization flags could be specified from the environment in
>CFLAGS
>> to override the defaults, but the per-target optimization level would
>> override that if it was lower.  Sounds difficult, though ...
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>For additional commands, e-mail: dev-h...@openoffice.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Don Lewis]

On 29 Nov, Jim Jagielski wrote:
> I'm just concerned about the CXXFLAGS interaction
> 
> The proposed patch breaks how I expect many people
> are building AOO and it's a regression that, unless
> we are super clear about it, would bite a lot of
> people.

How many people set CXXFLAGS in the environment?

Another way to do this is to change the gb_LinkTarget_set_*_optimization
functions to override CXXFLAGS, etc. instead of gb_COMPILEROPTFLAGS.
That would basically return us to the status quo where the usual way of
doing per-target overrides to this point has been:

# Work around bug in gcc 4.2 / 4.3, see
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35182
ifeq ($(COM),GCC)
$(eval $(call gb_Library_add_cxxobjects,sc,\
sc/source/ui/unoobj/chart2uno \
, $(gb_COMPILERNOOPTFLAGS) $(gb_LinkTarget_EXCEPTIONFLAGS) \
))
else
$(eval $(call gb_Library_add_exception_objects,sc,\
sc/source/ui/unoobj/chart2uno \
))
endif

which manages to lose the debug flags.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Jim Jagielski]

I'm just concerned about the CXXFLAGS interaction

The proposed patch breaks how I expect many people
are building AOO and it's a regression that, unless
we are super clear about it, would bite a lot of
people.

> On Nov 28, 2017, at 6:13 PM, Don Lewis  wrote:
> 
> On 28 Nov, Jim Jagielski wrote:
>> Wouldn't it make sense to do something like LOCAL_CFLAGS which
>> could then be manipulated?...
> 
> It depends on what the goal is.  What would be nice is if debug flags
> and optimization flags could be specified from the environment in CFLAGS
> to override the defaults, but the per-target optimization level would
> override that if it was lower.  Sounds difficult, though ...
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Don Lewis]

On 28 Nov, Jim Jagielski wrote:
> Wouldn't it make sense to do something like LOCAL_CFLAGS which
> could then be manipulated?...

It depends on what the goal is.  What would be nice is if debug flags
and optimization flags could be specified from the environment in CFLAGS
to override the defaults, but the per-target optimization level would
override that if it was lower.  Sounds difficult, though ...


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: a more sane way to override optimization flags in gbuild

[Jim Jagielski]

Wouldn't it make sense to do something like LOCAL_CFLAGS which
could then be manipulated?...

What I might do is commit this and then work on that ;)

> On Nov 28, 2017, at 4:42 AM, Don Lewis  wrote:
> 
> Here's a gbuild patch vs. trunk r1816518 that makes setting optimization
> level overrides for specific files a lot easier.  I also added a way to
> safely specify -O1 without breaking debug.  It's not perfect because if
> someone set CXXFLAGS in the environment, it will override the override
> in the .mk file.  It is only very lightly tested ... my FreeBSD build is
> only about halfway complete.
> 
> Index: main/framework/Library_fwk.mk
> ===
> --- main/framework/Library_fwk.mk (revision 1816518)
> +++ main/framework/Library_fwk.mk (working copy)
> @@ -61,6 +61,11 @@
>   $(gb_STDLIBS) \
> ))
> 
> +# i126622 - Base 4.1.2 does not open Tables and Queries in Mac OSX
> +ifeq ($(OS),MACOSX)
> +$(call 
> gb_LinkTarget_set_cxx_optimization,framework/source/loadenv/loadenv,$(gb_COMPILEROPT1FLAGS))
> +endif
> +
> $(eval $(call gb_Library_add_exception_objects,fwk,\
>   framework/source/accelerators/acceleratorcache \
>   framework/source/accelerators/acceleratorconfiguration \
> @@ -190,10 +195,4 @@
>   framework/source/xml/imagesdocumenthandler \
> ))
> 
> -# i126622 - Base 4.1.2 does not open Tables and Queries in Mac OSX
> -ifeq ($(OS),MACOSX)
> -$(call gb_CxxObject_get_target,framework/source/loadenv/loadenv):\
> - T_CXXFLAGS := $(gb_LinkTarget_CXXFLAGS) $(gb_LinkTarget_EXCEPTIONFLAGS) 
> $(gb_COMPILERNOOPTFLAGS)
> -endif
> -
> # vim: set noet sw=4 ts=4:
> Index: main/solenv/gbuild/LinkTarget.mk
> ===
> --- main/solenv/gbuild/LinkTarget.mk  (revision 1816518)
> +++ main/solenv/gbuild/LinkTarget.mk  (working copy)
> @@ -333,12 +333,12 @@
> $(call gb_LinkTarget_get_clean_target,$(1)) \
> $(call gb_LinkTarget_get_target,$(1)) : GENCXXOBJECTS :=
> $(call gb_LinkTarget_get_headers_target,$(1)) \
> -$(call gb_LinkTarget_get_target,$(1)) : T_CFLAGS := $$(gb_LinkTarget_CFLAGS) 
> $(CFLAGS)
> +$(call gb_LinkTarget_get_target,$(1)) : T_CFLAGS := $$(gb_LinkTarget_CFLAGS)
> $(call gb_LinkTarget_get_headers_target,$(1)) \
> $(call gb_LinkTarget_get_target,$(1)) : T_CXXFLAGS := 
> $$(gb_LinkTarget_CXXFLAGS)
> $(call gb_LinkTarget_get_headers_target,$(1)) \
> -$(call gb_LinkTarget_get_target,$(1)) : PCH_CXXFLAGS := 
> $$(gb_LinkTarget_CXXFLAGS) $(CXXFLAGS)
> -$(call gb_LinkTarget_get_target,$(1)) : T_OBJCXXFLAGS := 
> $$(gb_LinkTarget_OBJCXXFLAGS) $(OBJCXXFLAGS)
> +$(call gb_LinkTarget_get_target,$(1)) : PCH_CXXFLAGS := 
> $$(gb_LinkTarget_CXXFLAGS)
> +$(call gb_LinkTarget_get_target,$(1)) : T_OBJCXXFLAGS := 
> $$(gb_LinkTarget_OBJCXXFLAGS)
> $(call gb_LinkTarget_get_headers_target,$(1)) \
> $(call gb_LinkTarget_get_target,$(1)) : DEFS := $$(gb_LinkTarget_DEFAULTDEFS) 
> $(CPPFLAGS)
> $(call gb_LinkTarget_get_headers_target,$(1)) \
> @@ -367,10 +367,10 @@
> $(call gb_LinkTarget_get_dep_target,$(1)) : CXXOBJECTS := 
> $(call gb_LinkTarget_get_dep_target,$(1)) : OBJCXXOBJECTS :=
> $(call gb_LinkTarget_get_dep_target,$(1)) : GENCXXOBJECTS :=
> -$(call gb_LinkTarget_get_dep_target,$(1)) : T_CFLAGS := 
> $$(gb_LinkTarget_CFLAGS) $(CFLAGS)
> +$(call gb_LinkTarget_get_dep_target,$(1)) : T_CFLAGS := 
> $$(gb_LinkTarget_CFLAGS)
> $(call gb_LinkTarget_get_dep_target,$(1)) : T_CXXFLAGS := 
> $$(gb_LinkTarget_CXXFLAGS)
> -$(call gb_LinkTarget_get_dep_target,$(1)) : PCH_CXXFLAGS := 
> $$(gb_LinkTarget_CXXFLAGS) $(CXXFLAGS)
> -$(call gb_LinkTarget_get_dep_target,$(1)) : T_OBJCXXFLAGS := 
> $$(gb_LinkTarget_OBJCXXFLAGS) $(OBJCXXFLAGS)
> +$(call gb_LinkTarget_get_dep_target,$(1)) : PCH_CXXFLAGS := 
> $$(gb_LinkTarget_CXXFLAGS)
> +$(call gb_LinkTarget_get_dep_target,$(1)) : T_OBJCXXFLAGS := 
> $$(gb_LinkTarget_OBJCXXFLAGS)
> $(call gb_LinkTarget_get_dep_target,$(1)) : DEFS := 
> $$(gb_LinkTarget_DEFAULTDEFS) $(CPPFLAGS)
> $(call gb_LinkTarget_get_dep_target,$(1)) : PCH_DEFS := 
> $$(gb_LinkTarget_DEFAULTDEFS) $(CPPFLAGS)
> $(call gb_LinkTarget_get_dep_target,$(1)) : INCLUDE := 
> $$(gb_LinkTarget_INCLUDE)
> @@ -477,9 +477,24 @@
> $(call gb_LinkTarget_get_dep_target,$(1)) : T_OBJCXXFLAGS := $(2)
> endif
> endif
> +endef
> 
> +define gb_LinkTarget_set_c_optimization
> +$(call gb_CObject_get_target,$(1)) : gb_COMPILEROPTFLAGS := $(2)
> endef
> 
> +define gb_LinkTarget_set_cxx_optimization
> +$(call gb_CxxObject_get_target,$(1)) : gb_COMPILEROPTFLAGS := $(2)
> +endef
> +
> +define gb_LinkTarget_set_gencxx_optimization
> +$(call gb_GenCxxObject_get_target,$(1)) : gb_COMPILEROPTFLAGS := $(2)
> +endef
> +
> +define gb_LinkTarget_set_objcxx_optimization
> +$(call gb_ObjCxxObject_get_target,$(1)) : gb_COMPILEROPTFLAGS := $(2)
> +endef
> +
> define gb_LinkTarget_set_include
> $(call gb_LinkTarget_get_headers_target,$(1)) \
> $(call gb_LinkTarget_get_target,$(1)) :