date:20200423

Re: Update to python-2.17

2020-04-23 Thread Peter Kovacs


Hi all,


I have replaced everything 2.7.17 to 2.7.18. Added the Python file in 
downloads.


I would do now a test build.

After the test build how can I test if there are issues?


All the best

Peter

Am 21.04.20 um 18:40 schrieb Matthias Seidel:

Hi Marcus,

Am 21.04.20 um 18:33 schrieb Marcus:

Am 21.04.20 um 13:56 schrieb Matthias Seidel:

The final Python 2.7.18 is out:

https://www.python.org/downloads/release/python-2718/

I would expect no major changes to 2.7.17, so we could probably update
to that version?

is currently version 2.7.17 included? If so, then updating to .18 for
testing could be done.

Otherwise a more complicated update phase from somewhere to 2.7.18
should be done first.

Pedro did the update to 2.1.17 early this year [1].

So updating to the final 2.7.18 should be only minor adjustments.

Regards,

    Matthias

[1] https://github.com/apache/openoffice/pull/23


My 2 ct.

Marcus




Am 02.01.20 um 03:30 schrieb Pedro Giffuni:

Hello AOO devs and best wishes for the New Year!

Well ... time has passed and Python 2 is now deprecated!

I have a patch here to update AOO 4.2's version of Python to the latest
(perhaps last) release in that line:

http://people.apache.org/~pfg/patches/patch-python-2.17.diff

This is a remake of the previous update that I had made for
cpython-2.16, but which no one tested ! I currently lack an AOO setup
with git so please someone else will have to test and commit.

On the near term, we really should update to Python 3, but that will be
challenging for the build system since it requires a newer version of
the MS compiler.

Building with an external python is also currently broken for python
versions >= 3.6.


-
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: Update to python-2.17

2020-04-23 Thread Jim Jagielski

I agree. We should ensure that all works w/ 2.7.18 since it is the last of the 
Python 2.7s... even if it means we "fix" AOO to work with it, we should simply 
baseline that version.

> On Apr 21, 2020, at 7:56 AM, Matthias Seidel  
> wrote:
> 
> Hi all,
> 
> The final Python 2.7.18 is out:
> 
> https://www.python.org/downloads/release/python-2718/
> 
> I would expect no major changes to 2.7.17, so we could probably update
> to that version?
> 
> Regards,
> 
>Matthias
> 
> Am 02.01.20 um 03:30 schrieb Pedro Giffuni:
>> Hello AOO devs and best wishes for the New Year!
>> 
>> Well ... time has passed and Python 2 is now deprecated!
>> 
>> I have a patch here to update AOO 4.2's version of Python to the latest
>> (perhaps last) release in that line:
>> 
>> http://people.apache.org/~pfg/patches/patch-python-2.17.diff
>> 
>> This is a remake of the previous update that I had made for
>> cpython-2.16, but which no one tested ! I currently lack an AOO setup
>> with git so please someone else will have to test and commit.
>> 
>> On the near term, we really should update to Python 3, but that will be
>> challenging for the build system since it requires a newer version of
>> the MS compiler.
>> 
>> Building with an external python is also currently broken for python
>> versions >= 3.6.
>> 
>> Regards,
>> 
>> Pedro.
>> 
>> 
>> -
>> 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: Update to python-2.17

2020-04-23 Thread Matthias Seidel

Hi Jim,

Am 23.04.20 um 13:42 schrieb Jim Jagielski:
> I agree. We should ensure that all works w/ 2.7.18 since it is the last of 
> the Python 2.7s... even if it means we "fix" AOO to work with it, we should 
> simply baseline that version.
In trunk and AOO42X we are already on 2.7.17. No problems so far.

But in 4.1.7 we still ship 2.7.6 (?).

Regards,

   Matthias

>
>> On Apr 21, 2020, at 7:56 AM, Matthias Seidel  
>> wrote:
>>
>> Hi all,
>>
>> The final Python 2.7.18 is out:
>>
>> https://www.python.org/downloads/release/python-2718/
>>
>> I would expect no major changes to 2.7.17, so we could probably update
>> to that version?
>>
>> Regards,
>>
>>Matthias
>>
>> Am 02.01.20 um 03:30 schrieb Pedro Giffuni:
>>> Hello AOO devs and best wishes for the New Year!
>>>
>>> Well ... time has passed and Python 2 is now deprecated!
>>>
>>> I have a patch here to update AOO 4.2's version of Python to the latest
>>> (perhaps last) release in that line:
>>>
>>> http://people.apache.org/~pfg/patches/patch-python-2.17.diff
>>>
>>> This is a remake of the previous update that I had made for
>>> cpython-2.16, but which no one tested ! I currently lack an AOO setup
>>> with git so please someone else will have to test and commit.
>>>
>>> On the near term, we really should update to Python 3, but that will be
>>> challenging for the build system since it requires a newer version of
>>> the MS compiler.
>>>
>>> Building with an external python is also currently broken for python
>>> versions >= 3.6.
>>>
>>> Regards,
>>>
>>> Pedro.
>>>
>>>
>>> -
>>> 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
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Update to python-2.17

2020-04-23 Thread Matthias Seidel

Hi Peter,

Am 23.04.20 um 10:04 schrieb Peter Kovacs:
> Hi all,
>
>
> I have replaced everything 2.7.17 to 2.7.18. Added the Python file in
> downloads.
>
> I would do now a test build.
Great!
>
> After the test build how can I test if there are issues?

Simply run the Python scripts in Writer. That's what I did... ;-)

Regards,

   Matthias

>
>
> All the best
>
> Peter
>
> Am 21.04.20 um 18:40 schrieb Matthias Seidel:
>> Hi Marcus,
>>
>> Am 21.04.20 um 18:33 schrieb Marcus:
>>> Am 21.04.20 um 13:56 schrieb Matthias Seidel:
 The final Python 2.7.18 is out:

 https://www.python.org/downloads/release/python-2718/

 I would expect no major changes to 2.7.17, so we could probably update
 to that version?
>>> is currently version 2.7.17 included? If so, then updating to .18 for
>>> testing could be done.
>>>
>>> Otherwise a more complicated update phase from somewhere to 2.7.18
>>> should be done first.
>> Pedro did the update to 2.1.17 early this year [1].
>>
>> So updating to the final 2.7.18 should be only minor adjustments.
>>
>> Regards,
>>
>>     Matthias
>>
>> [1] https://github.com/apache/openoffice/pull/23
>>
>>> My 2 ct.
>>>
>>> Marcus
>>>
>>>
>>>
 Am 02.01.20 um 03:30 schrieb Pedro Giffuni:
> Hello AOO devs and best wishes for the New Year!
>
> Well ... time has passed and Python 2 is now deprecated!
>
> I have a patch here to update AOO 4.2's version of Python to the
> latest
> (perhaps last) release in that line:
>
> http://people.apache.org/~pfg/patches/patch-python-2.17.diff
>
> This is a remake of the previous update that I had made for
> cpython-2.16, but which no one tested ! I currently lack an AOO setup
> with git so please someone else will have to test and commit.
>
> On the near term, we really should update to Python 3, but that
> will be
> challenging for the build system since it requires a newer version of
> the MS compiler.
>
> Building with an external python is also currently broken for python
> versions >= 3.6.
>>>
>>> -
>>> 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
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Update to python-2.17

2020-04-23 Thread Jim Jagielski




> On Apr 23, 2020, at 8:50 AM, Matthias Seidel  
> wrote:
> 
> Hi Jim,
> 
> Am 23.04.20 um 13:42 schrieb Jim Jagielski:
>> I agree. We should ensure that all works w/ 2.7.18 since it is the last of 
>> the Python 2.7s... even if it means we "fix" AOO to work with it, we should 
>> simply baseline that version.
> In trunk and AOO42X we are already on 2.7.17. No problems so far.

Yeah, I think in trunk and AOO42X we should just go w/ 2.7.18... Bite the 
bullet now.

> 
> But in 4.1.7 we still ship 2.7.6 (?).

I agree that we don't mess w/ 4.1.X

> 
> Regards,
> 
>Matthias
> 
>> 
>>> On Apr 21, 2020, at 7:56 AM, Matthias Seidel  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> The final Python 2.7.18 is out:
>>> 
>>> https://www.python.org/downloads/release/python-2718/
>>> 
>>> I would expect no major changes to 2.7.17, so we could probably update
>>> to that version?
>>> 
>>> Regards,
>>> 
>>>   Matthias
>>> 
>>> Am 02.01.20 um 03:30 schrieb Pedro Giffuni:
 Hello AOO devs and best wishes for the New Year!
 
 Well ... time has passed and Python 2 is now deprecated!
 
 I have a patch here to update AOO 4.2's version of Python to the latest
 (perhaps last) release in that line:
 
 http://people.apache.org/~pfg/patches/patch-python-2.17.diff
 
 This is a remake of the previous update that I had made for
 cpython-2.16, but which no one tested ! I currently lack an AOO setup
 with git so please someone else will have to test and commit.
 
 On the near term, we really should update to Python 3, but that will be
 challenging for the build system since it requires a newer version of
 the MS compiler.
 
 Building with an external python is also currently broken for python
 versions >= 3.6.
 
 Regards,
 
 Pedro.
 
 
 -
 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: Update to python-2.17

2020-04-23 Thread Matthias Seidel

Hi Jim,

Am 23.04.20 um 15:21 schrieb Jim Jagielski:
>
>> On Apr 23, 2020, at 8:50 AM, Matthias Seidel  
>> wrote:
>>
>> Hi Jim,
>>
>> Am 23.04.20 um 13:42 schrieb Jim Jagielski:
>>> I agree. We should ensure that all works w/ 2.7.18 since it is the last of 
>>> the Python 2.7s... even if it means we "fix" AOO to work with it, we should 
>>> simply baseline that version.
>> In trunk and AOO42X we are already on 2.7.17. No problems so far.
> Yeah, I think in trunk and AOO42X we should just go w/ 2.7.18... Bite the 
> bullet now.

I really don't expect problems here. Let's see what Peter can say about
his test build.

Matthias

>
>> But in 4.1.7 we still ship 2.7.6 (?).
> I agree that we don't mess w/ 4.1.X
>
>> Regards,
>>
>>Matthias
>>
 On Apr 21, 2020, at 7:56 AM, Matthias Seidel  
 wrote:

 Hi all,

 The final Python 2.7.18 is out:

 https://www.python.org/downloads/release/python-2718/

 I would expect no major changes to 2.7.17, so we could probably update
 to that version?

 Regards,

   Matthias

 Am 02.01.20 um 03:30 schrieb Pedro Giffuni:
> Hello AOO devs and best wishes for the New Year!
>
> Well ... time has passed and Python 2 is now deprecated!
>
> I have a patch here to update AOO 4.2's version of Python to the latest
> (perhaps last) release in that line:
>
> http://people.apache.org/~pfg/patches/patch-python-2.17.diff
>
> This is a remake of the previous update that I had made for
> cpython-2.16, but which no one tested ! I currently lack an AOO setup
> with git so please someone else will have to test and commit.
>
> On the near term, we really should update to Python 3, but that will be
> challenging for the build system since it requires a newer version of
> the MS compiler.
>
> Building with an external python is also currently broken for python
> versions >= 3.6.
>
> Regards,
>
> Pedro.
>
>
> -
> 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
>



smime.p7s
Description: S/MIME Cryptographic Signature

Re: about build environment development

2020-04-23 Thread Jim Jagielski

IMO, dmake is simply a build-and-compile dependency. Considering that we pull 
in lots of other external dependencies, keeping or dropping dmake will likely 
not make any real difference in the people we can attract to help develop, test 
and build AOO. At the very least, we know what dmake is good at, and what it is 
NOT good at; so I support porting as much as possible to gmake, and just using 
dmake as the last step.

And, FWIW, I am keeping dmake up-to-date and even FreeBSD are using my repo 
now: https://github.com/jimjag/dmake

> On Apr 17, 2020, at 8:53 AM, Peter Kovacs  wrote:
> 
> The goal is to move away from dmake. I do struggle with your point of view, 
> saying moving away from dmake is unimportant, and should be stopped.
> 
> I disagree with this position.
> 
> 
> Am 16.04.20 um 23:04 schrieb Patricia Shanahan:
>> 
>> 
>> On 4/15/2020 10:08 AM, Damjan Jovanovic wrote:
>>> On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski  wrote:
>>> 
 
 
> On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic  wrote:
> 
> 
> We are also thin on new contributors, and I recall you saying they're
> largely scared off by the current build system.
> 
 
 Two points:
 
1. I doubt that by the time we finish porting to a whole new build
 system, we will even have anyone *wanting* to contribute. With each delay
 and push-out on releases, and more time spent working on the build system
 instead of AOO itself, we become less and less relevant. Is that really a
 priority we should be focusing on? Are the number of people knowledgeable
 around scons really greater than what we have now? But I could be wrong,
 which leads me to #2...
 
 
>>> What would you recommend we focus on instead then?
>> 
>> I would recommend going for robustness, rather than new features. I know of 
>> some areas for potential improvement:
>> 
>> Array bounds checking, especially during input processing.
>> 
>> Memory allocation checking.
>> 
>> Debug profile corruption.
>> 
>>> 
>>> Ideally, new contributors wouldn't need to be knowledgeable about scons.
>>> The build should be easier to perform, hopefully just "./configure"
>>> followed by "scons" (and scons even implements features that can subsume
>>> ./configure too). Already, scons doesn't need the "source winenv.set.sh"
>>> and "cd instsetoo_native" steps to build its modules.
>>> 
>>> 
2. "The conversion from gbuild to scons would largely be automated, fast
 and correct." If that is the case, let's test that theory right now.
 
>>> 
>>> This has been possible for some time. In the scons-build branch, you can do
>>> the following:
>>> 
>>> $ cd gotoSCons
>>> $ mvn package
>>> $ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
>>> org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis ../main
>>> (per-module output)
>>> Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
>>> drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
>>> registry, remotebridges, sane, store, svgio, twain, ucbhelper, unixODBC,
>>> xmlreader, xmlscript]
>>> 22 out of 105 gbuild modules are parseable
>>> 
>>> That means 22 modules can already be converted, completely and correctly.
>>> As we add more features to the converter (AllLangResTarget, UnoApi, Junit,
>>> GoogleTest, etc.), that 22 will increase.
>>> 
>>> The per-module gbuild files are easy to parse. Parsing the syntax takes
>>> only 3 methods and < 100 lines of Java. The non-deterministic ones with
>>> "ifeq ($(GUIBASE),aqua)" require some manual work, but even there, a lot
>>> can be automated. There is some more work involved in semantic conversion:
>>> understanding and converting specific gbuild commands, converting paths to
>>> scons format, etc. but even so, we're on just 1913 lines of code in total
>>> for the converter.
>>> 
>>> The hard part is to convert gbuild functions in main/solenv/gbuild into
>>> scons, for example, the worst case scenario is AllLangResTarget, for which
>>> this monstrous dependency tree needs to be implemented, with 4 layers of
>>> intermediate targets and complex actions with side effects and header
>>> dependencies (not shown):
>>> 
>>> #  AllLangResTarget(name)
>>> #  (meta-target; delivers an empty timestamp file)
>>> #^ ^
>>> #   /   \
>>> #  / \
>>> # /   \
>>> #  ResTarget(nameen-US,name,en-US)
>>> ResTarget(nameen-GB,name,en-GB)
>>> #  $(WORKDIR)/ResTarget/$(resName).res
>>> $(WORKDIR)/ResTarget/$(resName).res
>>> #  $(WORKDIR)/ResTarget/nameen-US.res
>>>   $(WORKDIR)/ResTarget/nameen-GB.res
>>> #^ ^^
>>> #| rsc ||
>>> #| ||
>>> #  SrsTarget   SrsTarget
>>> SrsTarge

Re: about build environment development

2020-04-23 Thread Peter Kovacs

Hi Jim,

dmake is not simple. I do know nothing Jim Jagielski...

Today the build system enjoys me with

checking whether the found dmake is the right dmake... configure:
WARNING: no

configure: error: no URL for dmake source code specified, either. Use
--with-dmake-url to supply an URL; run configure with the --help option
for a list of possible URLs.
./configure.sh: Zeile 22:
--with-dmake-url=https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2:
Datei oder Verzeichnis nicht gefunden

but:

wget
https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
dmake-4.12.tar.bz2
100%[==>]
490,31K 92,2KB/s in 5,3s

I am frustrated and will continue, when I had a break. Maybe then I
figure out what stupidity I do not see.

All the Best

Peter

Am 23.04.20 um 15:48 schrieb Jim Jagielski:

IMO, dmake is simply a build-and-compile dependency. Considering that we pull
in lots of other external dependencies, keeping or dropping dmake will likely
not make any real difference in the people we can attract to help develop, test
and build AOO. At the very least, we know what dmake is good at, and what it is
NOT good at; so I support porting as much as possible to gmake, and just using
dmake as the last step.

And, FWIW, I am keeping dmake up-to-date and even FreeBSD are using my repo
now: https://github.com/jimjag/dmake

On Apr 17, 2020, at 8:53 AM, Peter Kovacs wrote:

The goal is to move away from dmake. I do struggle with your point of view,
saying moving away from dmake is unimportant, and should be stopped.

I disagree with this position.

Am 16.04.20 um 23:04 schrieb Patricia Shanahan:

On 4/15/2020 10:08 AM, Damjan Jovanovic wrote:

On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski wrote:

On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic wrote:

We are also thin on new contributors, and I recall you saying they're
largely scared off by the current build system.

Two points:

1. I doubt that by the time we finish porting to a whole new build
system, we will even have anyone *wanting* to contribute. With each delay
and push-out on releases, and more time spent working on the build system
instead of AOO itself, we become less and less relevant. Is that really a
priority we should be focusing on? Are the number of people knowledgeable
around scons really greater than what we have now? But I could be wrong,
which leads me to #2...

What would you recommend we focus on instead then?

I would recommend going for robustness, rather than new features. I know of
some areas for potential improvement:

Array bounds checking, especially during input processing.

Memory allocation checking.

Debug profile corruption.

Ideally, new contributors wouldn't need to be knowledgeable about scons.
The build should be easier to perform, hopefully just "./configure"
followed by "scons" (and scons even implements features that can subsume
./configure too). Already, scons doesn't need the "source winenv.set.sh"
and "cd instsetoo_native" steps to build its modules.

2. "The conversion from gbuild to scons would largely be automated, fast
and correct." If that is the case, let's test that theory right now.

This has been possible for some time. In the scons-build branch, you can do
the following:

$ cd gotoSCons
$ mvn package
$ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis ../main
(per-module output)
Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
registry, remotebridges, sane, store, svgio, twain, ucbhelper, unixODBC,
xmlreader, xmlscript]
22 out of 105 gbuild modules are parseable

That means 22 modules can already be converted, completely and correctly.
As we add more features to the converter (AllLangResTarget, UnoApi, Junit,
GoogleTest, etc.), that 22 will increase.

The per-module gbuild files are easy to parse. Parsing the syntax takes
only 3 methods and < 100 lines of Java. The non-deterministic ones with
"ifeq ($(GUIBASE),aqua)" require some manual work, but even there, a lot
can be automated. There is some more work involved in semantic conversion:
understanding and converting specific gbuild commands, converting paths to
scons format, etc. but even so, we're on just 1913 lines of code in total
for the converter.

The hard part is to convert gbuild functions in main/solenv/gbuild into
scons, for example, the worst case scenario is AllLangResTarget, for which
this monstrous dependency tree needs to be implemented, with 4 layers of
intermediate targets and complex actions with side effects and header
dependencies (not shown):

# AllLangResTarget(name)
# (meta-target; delivers an empty timestamp file

Re: about build environment development

2020-04-23 Thread Kay Schenk

On 4/23/20 10:44 AM, Peter Kovacs wrote:

Hi Jim,

dmake is not simple. I do know nothing Jim Jagielski...

Today the build system enjoys me with

checking whether the found dmake is the right dmake... configure:
WARNING: no

configure: error: no URL for dmake source code specified, either. Use
--with-dmake-url to supply an URL; run configure with the --help
option for a list of possible URLs.
./configure.sh: Zeile 22:
--with-dmake-url=https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2:
Datei oder Verzeichnis nicht gefunden

but:

wget
https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2
dmake-4.12.tar.bz2
100%[==>]
490,31K 92,2KB/s in 5,3s

I am frustrated and will continue, when I had a break. Maybe then I
figure out what stupidity I do not see.

All the Best

Peter

Maybe some useful information on dmake?

https://docs.oracle.com/cd/E19422-01/819-3697/dmake.html

Regards,

Kay

Am 23.04.20 um 15:48 schrieb Jim Jagielski:
IMO, dmake is simply a build-and-compile dependency. Considering that
we pull in lots of other external dependencies, keeping or dropping
dmake will likely not make any real difference in the people we can
attract to help develop, test and build AOO. At the very least, we
know what dmake is good at, and what it is NOT good at; so I support
porting as much as possible to gmake, and just using dmake as the
last step.

And, FWIW, I am keeping dmake up-to-date and even FreeBSD are using
my repo now: https://github.com/jimjag/dmake

On Apr 17, 2020, at 8:53 AM, Peter Kovacs wrote:

The goal is to move away from dmake. I do struggle with your point
of view, saying moving away from dmake is unimportant, and should be
stopped.

I disagree with this position.

Am 16.04.20 um 23:04 schrieb Patricia Shanahan:

On 4/15/2020 10:08 AM, Damjan Jovanovic wrote:
On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski
wrote:

On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic
wrote:

We are also thin on new contributors, and I recall you saying
they're

largely scared off by the current build system.

Two points:

1. I doubt that by the time we finish porting to a whole new
build
system, we will even have anyone *wanting* to contribute. With
each delay
and push-out on releases, and more time spent working on the
build system
instead of AOO itself, we become less and less relevant. Is that
really a
priority we should be focusing on? Are the number of people
knowledgeable
around scons really greater than what we have now? But I could be
wrong,

which leads me to #2...

What would you recommend we focus on instead then?
I would recommend going for robustness, rather than new features. I
know of some areas for potential improvement:

Array bounds checking, especially during input processing.

Memory allocation checking.

Debug profile corruption.

Ideally, new contributors wouldn't need to be knowledgeable about
scons.

The build should be easier to perform, hopefully just "./configure"
followed by "scons" (and scons even implements features that can
subsume
./configure too). Already, scons doesn't need the "source
winenv.set.sh"

and "cd instsetoo_native" steps to build its modules.

2. "The conversion from gbuild to scons would largely be
automated, fast

and correct." If that is the case, let's test that theory right now.

This has been possible for some time. In the scons-build branch,
you can do

the following:

$ cd gotoSCons
$ mvn package
$ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis
../main

(per-module output)
Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
registry, remotebridges, sane, store, svgio, twain, ucbhelper,
unixODBC,

xmlreader, xmlscript]
22 out of 105 gbuild modules are parseable

That means 22 modules can already be converted, completely and
correctly.
As we add more features to the converter (AllLangResTarget,
UnoApi, Junit,

GoogleTest, etc.), that 22 will increase.

The per-module gbuild files are easy to parse. Parsing the syntax
takes
only 3 methods and < 100 lines of Java. The non-deterministic ones
with
"ifeq ($(GUIBASE),aqua)" require some manual work, but even there,
a lot
can be automated. There is some more work involved in semantic
conversion:
understanding and converting specific gbuild commands, converting
paths to
scons format, etc. but even so, we're on just 1913 lines of code
in total

for the converter.

intermediate ta

Re: about build environment development

2020-04-23 Thread Peter Kovacs


fixed my issues.

Jim, I had an install issue with latest trunk of your epm repo:


make: INSTALL@: Befehl nicht gefunden (command not found)
Makefile:153: die Regel für Ziel „install“ scheiterte (install failed)
make: *** [install] Fehler 127


I think some sort of typo maybe? 4.4.2 works good.


All the best

Peter

Am 23.04.20 um 15:48 schrieb Jim Jagielski:

IMO, dmake is simply a build-and-compile dependency. Considering that we pull 
in lots of other external dependencies, keeping or dropping dmake will likely 
not make any real difference in the people we can attract to help develop, test 
and build AOO. At the very least, we know what dmake is good at, and what it is 
NOT good at; so I support porting as much as possible to gmake, and just using 
dmake as the last step.

And, FWIW, I am keeping dmake up-to-date and even FreeBSD are using my repo 
now: https://github.com/jimjag/dmake


On Apr 17, 2020, at 8:53 AM, Peter Kovacs  wrote:

The goal is to move away from dmake. I do struggle with your point of view, 
saying moving away from dmake is unimportant, and should be stopped.

I disagree with this position.


Am 16.04.20 um 23:04 schrieb Patricia Shanahan:


On 4/15/2020 10:08 AM, Damjan Jovanovic wrote:

On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski  wrote:




On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic  wrote:


We are also thin on new contributors, and I recall you saying they're
largely scared off by the current build system.


Two points:

1. I doubt that by the time we finish porting to a whole new build
system, we will even have anyone *wanting* to contribute. With each delay
and push-out on releases, and more time spent working on the build system
instead of AOO itself, we become less and less relevant. Is that really a
priority we should be focusing on? Are the number of people knowledgeable
around scons really greater than what we have now? But I could be wrong,
which leads me to #2...



What would you recommend we focus on instead then?

I would recommend going for robustness, rather than new features. I know of 
some areas for potential improvement:

Array bounds checking, especially during input processing.

Memory allocation checking.

Debug profile corruption.


Ideally, new contributors wouldn't need to be knowledgeable about scons.
The build should be easier to perform, hopefully just "./configure"
followed by "scons" (and scons even implements features that can subsume
./configure too). Already, scons doesn't need the "source winenv.set.sh"
and "cd instsetoo_native" steps to build its modules.



2. "The conversion from gbuild to scons would largely be automated, fast
and correct." If that is the case, let's test that theory right now.


This has been possible for some time. In the scons-build branch, you can do
the following:

$ cd gotoSCons
$ mvn package
$ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis ../main
(per-module output)
Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
registry, remotebridges, sane, store, svgio, twain, ucbhelper, unixODBC,
xmlreader, xmlscript]
22 out of 105 gbuild modules are parseable

That means 22 modules can already be converted, completely and correctly.
As we add more features to the converter (AllLangResTarget, UnoApi, Junit,
GoogleTest, etc.), that 22 will increase.

The per-module gbuild files are easy to parse. Parsing the syntax takes
only 3 methods and < 100 lines of Java. The non-deterministic ones with
"ifeq ($(GUIBASE),aqua)" require some manual work, but even there, a lot
can be automated. There is some more work involved in semantic conversion:
understanding and converting specific gbuild commands, converting paths to
scons format, etc. but even so, we're on just 1913 lines of code in total
for the converter.

The hard part is to convert gbuild functions in main/solenv/gbuild into
scons, for example, the worst case scenario is AllLangResTarget, for which
this monstrous dependency tree needs to be implemented, with 4 layers of
intermediate targets and complex actions with side effects and header
dependencies (not shown):

#  AllLangResTarget(name)
#  (meta-target; delivers an empty timestamp file)
#^ ^
#   /   \
#  / \
# /   \
#  ResTarget(nameen-US,name,en-US)
ResTarget(nameen-GB,name,en-GB)
#  $(WORKDIR)/ResTarget/$(resName).res
$(WORKDIR)/ResTarget/$(resName).res
#  $(WORKDIR)/ResTarget/nameen-US.res
   $(WORKDIR)/ResTarget/nameen-GB.res
#^ ^^
#| rsc ||
#| ||
#  SrsTarget   SrsTarget
SrsTarget
#  $(WORKDIR)/SrsTarget/$(srsName).srs
#

Problem building Cui in Trunk

2020-04-23 Thread Peter Kovacs


Build broke with

=
Building module cui
=

Entering /home/legine/workspace/AOO/gitbox/main/cui/prj

cd .. && make -s -r -j1   && make -s -r deliverlog
/home/legine/workspace/AOO/gitbox/main/cui/Library_cui.mk:37: *** 
missing separator.  Stop.

dmake:  Error code 2, while making 'all'

The Line I have in code:

ifneq ($(strip $(BUILD_VER_STRING)),)
$(eval $(call 
gb_Library_add_defs,cui,-DBUILD_VER_STRING="$(BUILD_VER_STRING)"))

endif

Anyone has an Idea what this is about?

The latest change was in


	newtabledlg.src 
 
	Cleaned up resource file 
 
	11 days ago


But that does not look related.

I tried as fix

ifneq ($(strip $(BUILD_VER_STRING)))

but I am unsure if that is the issue.

Issue in vbahelper

2020-04-23 Thread Peter Kovacs


Hello all,

Build broke again, this time with Following Output:

   =
   Building module vbahelper
   =

   Entering /home/legine/workspace/AOO/gitbox/main/vbahelper/prj

   cd .. && make -s -r -j1   && make -s -r deliverlog
   [ info  ALL ] LinkTarget Library/libmsfilter.so not defined:
   Assuming headers to be there!
   [ build PKG ] vbahelper_inc
   [ build CXX ] vbahelper/source/msforms/service
   [ build CXX ] vbahelper/source/msforms/vbabutton
   [ build CXX ] vbahelper/source/msforms/vbacheckbox
   [ build CXX ] vbahelper/source/msforms/vbacombobox
   [ build CXX ] vbahelper/source/msforms/vbacontrol
   [ build CXX ] vbahelper/source/msforms/vbacontrols
   [ build CXX ] vbahelper/source/msforms/vbaframe
   [ build CXX ] vbahelper/source/msforms/vbaimage
   [ build CXX ] vbahelper/source/msforms/vbalabel
   [ build CXX ] vbahelper/source/msforms/vbalistbox
   [ build CXX ] vbahelper/source/msforms/vbalistcontrolhelper
   [ build CXX ] vbahelper/source/msforms/vbamultipage
   [ build CXX ] vbahelper/source/msforms/vbanewfont
   [ build CXX ] vbahelper/source/msforms/vbapages
   [ build CXX ] vbahelper/source/msforms/vbaprogressbar
   [ build CXX ] vbahelper/source/msforms/vbaradiobutton
   [ build CXX ] vbahelper/source/msforms/vbascrollbar
   [ build CXX ] vbahelper/source/msforms/vbaspinbutton
   [ build CXX ] vbahelper/source/msforms/vbasystemaxcontrol
   [ build CXX ] vbahelper/source/msforms/vbatextbox
   [ build CXX ] vbahelper/source/msforms/vbatogglebutton
   [ build CXX ] vbahelper/source/msforms/vbauserform
   [ build DEP ] LNK:Library/msforms.uno.so
   [ build CXX ] vbahelper/source/vbahelper/collectionbase
   [ build CXX ] vbahelper/source/vbahelper/vbaapplicationbase
   
/home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:
   fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory
   compilation terminated.
   [ build CXX ] vbahelper/source/vbahelper/vbaapplicationbase
   
/home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:
   fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory
   compilation terminated.
   /home/legine/workspace/AOO/gitbox/main/solenv/gbuild/Library.mk:48:
   *** gb_Deliver_deliver: file does not exist in solver, and cannot be
   delivered:
   
/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/lib/libmsfilter.so.
   Stop.
   dmake:  Error code 2, while making 'all'

I guess this is a dependency Issue?

[ info  ALL ] LinkTarget Library/libmsfilter.so not defined: Assuming 
headers to be there!


And

/home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43: 
fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory


and

/home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43: 
fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory


sounds like some idl has not been executed. I guess if someone is lucky 
then some other build module does this.



I try to just do a rerun, and cross fingers it will pass. Inn the 
meantime How do I check dependencies?


Thanks


All the Best

Peter

Issue in desktop?

2020-04-23 Thread Peter Kovacs

Okay, I try to sit this out by restart the build. Guessing it is a 
possible dependency breaker.



=
Building module desktop
=

Entering /home/legine/workspace/AOO/gitbox/main/desktop/test/deployment/boxt

mkout -- version: 1.8
Making:    all_test_deployment_boxt.dpslo
Compiling: desktop/unxlngx6.pro/misc/boxt.uno_version.c
Compiling: desktop/test/deployment/boxt/boxt.cxx
/home/legine/workspace/AOO/gitbox/main/desktop/test/deployment/boxt/boxt.cxx:45:41: 
fatal error: filter/msfilter/countryid.hxx: No such file or directory

compilation terminated.
dmake:  Error code 1, while making '../../../unxlngx6.pro/slo/boxt.obj'


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

Re: Problem building Cui in Trunk

2020-04-23 Thread Peter Kovacs


Okay the colon was not the issue. :/

Am 24.04.20 um 05:09 schrieb Peter Kovacs:

Build broke with

=
Building module cui
=

Entering /home/legine/workspace/AOO/gitbox/main/cui/prj

cd .. && make -s -r -j1   && make -s -r deliverlog
/home/legine/workspace/AOO/gitbox/main/cui/Library_cui.mk:37: *** 
missing separator.  Stop.

dmake:  Error code 2, while making 'all'

The Line I have in code:

ifneq ($(strip $(BUILD_VER_STRING)),)
$(eval $(call 
gb_Library_add_defs,cui,-DBUILD_VER_STRING="$(BUILD_VER_STRING)"))

endif

Anyone has an Idea what this is about?

The latest change was in


newtabledlg.src 
 
Cleaned up resource file 
 
11 days ago


But that does not look related.

I tried as fix

ifneq ($(strip $(BUILD_VER_STRING)))

but I am unsure if that is the issue.





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

Re: Problem building Cui in Trunk

2020-04-23 Thread Peter Kovacs


lol Google gives:

As indicated in the online manual, the most common cause for that 
*error* is that lines are indented with whitespaces when |make| expects 
tab characters.


Correct

target:\tcmd

where \t is TAB

Wrong

target:cmd


Anyways, I figured that build -v in the module gives a debug output, but 
it did not help. because gmake is handling the case.


I managed to run make, but I end up with the same issue. and make -d is 
less then helpful. I am out of Ideas for now.


=
Building module cui
=

Entering /home/legine/workspace/AOO/gitbox/main/cui/prj

dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/startup/startup.mk] 
for read (success)

dmake:  Openning [project.mk] for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/project.mk] 
for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/project.mk] for read 
(fail)

dmake:  Include file [project.mk] was not found.
dmake:  Closing 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/startup/startup.mk]

dmake:  Openning [makefile.mk] for read (success)
dmake:  Openning [settings.mk] for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/settings.mk] 
for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/settings.mk] for read 
(success)

dmake:  Parsing include file [settings.mk].
dmake:  Openning [ooo_vendor.mk] for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/ooo_vendor.mk] 
for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/ooo_vendor.mk] for 
read (fail)

dmake:  Inferring include file [ooo_vendor.mk].
dmake:  Openning [ooo_vendor.mk] for read (fail)
dmake:  Infering prerequisite(s) and recipe for [ooo_vendor.mk]
dmake:  Caching directory [/home/legine/workspace/AOO/gitbox/main/cui/prj]
dmake:  Time stamp of [ooo_vendor.mk] is 0
dmake:  Include file [ooo_vendor.mk] was not found.
dmake:  Openning [unitools.mk] for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/unitools.mk] 
for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/unitools.mk] for read 
(success)

dmake:  Parsing include file [unitools.mk].
dmake:  Closing 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/unitools.mk]

dmake:  Openning [minor.mk] for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/minor.mk] 
for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/minor.mk] for read 
(success)

dmake:  Parsing include file [minor.mk].
dmake:  Closing [/home/legine/workspace/AOO/gitbox/main/solenv/inc/minor.mk]
dmake:  Openning [rtlbootstrap.mk] for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/rtlbootstrap.mk] 
for read (success)

dmake:  Parsing include file [rtlbootstrap.mk].
dmake:  Closing 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/rtlbootstrap.mk]
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/450minor.mk] 
for read (success)
dmake:  Parsing include file 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/450minor.mk].
dmake:  Closing 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/450minor.mk]

dmake:  Openning [udkversion.mk] for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/udkversion.mk] 
for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/udkversion.mk] for 
read (success)

dmake:  Parsing include file [udkversion.mk].
dmake:  Closing 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/udkversion.mk]

dmake:  Openning [lang.mk] for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/lang.mk] 
for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/lang.mk] for read 
(success)

dmake:  Parsing include file [lang.mk].
dmake:  Closing [/home/legine/workspace/AOO/gitbox/main/solenv/inc/lang.mk]
dmake:  Openning [postset.mk] for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/postset.mk] 
for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/postset.mk] for read 
(success)

dmake:  Parsing include file [postset.mk].
dmake:  Openning [langlist.mk] for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solver/450/unxlngx6.pro/inc/langlist.mk] 
for read (fail)
dmake:  Openning 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/langlist.mk] for read 
(success)

dmake:  Parsing include file [langlist.mk].
dmake:  Closing 
[/home/legine/workspace/AOO/gitbox/main/solenv/inc/langlist.mk]
dmake:  Closing 
[/home/legine/workspace/AOO/g

Re: Issue in vbahelper

2020-04-23 Thread Damjan Jovanovic

On Fri, Apr 24, 2020 at 5:18 AM Peter Kovacs  wrote:

> Hello all,
>
> Build broke again, this time with Following Output:
>
> =
> Building module vbahelper
> =
>
> Entering /home/legine/workspace/AOO/gitbox/main/vbahelper/prj
>
> cd .. && make -s -r -j1   && make -s -r deliverlog
> [ info  ALL ] LinkTarget Library/libmsfilter.so not defined:
> Assuming headers to be there!
> [ build PKG ] vbahelper_inc
> [ build CXX ] vbahelper/source/msforms/service
> [ build CXX ] vbahelper/source/msforms/vbabutton
> [ build CXX ] vbahelper/source/msforms/vbacheckbox
> [ build CXX ] vbahelper/source/msforms/vbacombobox
> [ build CXX ] vbahelper/source/msforms/vbacontrol
> [ build CXX ] vbahelper/source/msforms/vbacontrols
> [ build CXX ] vbahelper/source/msforms/vbaframe
> [ build CXX ] vbahelper/source/msforms/vbaimage
> [ build CXX ] vbahelper/source/msforms/vbalabel
> [ build CXX ] vbahelper/source/msforms/vbalistbox
> [ build CXX ] vbahelper/source/msforms/vbalistcontrolhelper
> [ build CXX ] vbahelper/source/msforms/vbamultipage
> [ build CXX ] vbahelper/source/msforms/vbanewfont
> [ build CXX ] vbahelper/source/msforms/vbapages
> [ build CXX ] vbahelper/source/msforms/vbaprogressbar
> [ build CXX ] vbahelper/source/msforms/vbaradiobutton
> [ build CXX ] vbahelper/source/msforms/vbascrollbar
> [ build CXX ] vbahelper/source/msforms/vbaspinbutton
> [ build CXX ] vbahelper/source/msforms/vbasystemaxcontrol
> [ build CXX ] vbahelper/source/msforms/vbatextbox
> [ build CXX ] vbahelper/source/msforms/vbatogglebutton
> [ build CXX ] vbahelper/source/msforms/vbauserform
> [ build DEP ] LNK:Library/msforms.uno.so
> [ build CXX ] vbahelper/source/vbahelper/collectionbase
> [ build CXX ] vbahelper/source/vbahelper/vbaapplicationbase
>
> /home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:
> fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory
> compilation terminated.
> [ build CXX ] vbahelper/source/vbahelper/vbaapplicationbase
>
> /home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:
> fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory
> compilation terminated.
> /home/legine/workspace/AOO/gitbox/main/solenv/gbuild/Library.mk:48:
> *** gb_Deliver_deliver: file does not exist in solver, and cannot be
> delivered:
> /home/legine/workspace/AOO/gitbox/main/solver/450/
> unxlngx6.pro/lib/libmsfilter.so.
> Stop.
> dmake:  Error code 2, while making 'all'
>
> I guess this is a dependency Issue?
>
> [ info  ALL ] LinkTarget Library/libmsfilter.so not defined: Assuming
> headers to be there!
>
> And
>
> /home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:
>
> fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory
>
> and
>
> /home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:
>
> fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory
>
> sounds like some idl has not been executed. I guess if someone is lucky
> then some other build module does this.
>
>
> I try to just do a rerun, and cross fingers it will pass. Inn the
> meantime How do I check dependencies?
>
> Thanks
>
>
> All the Best
>
> Peter
>
>
main/vbahelper/prj/build.lst already lists filter as a dependency. It
sounds like the filter module failed to build?

Damjan

Re: Issue in vbahelper

2020-04-23 Thread Peter Kovacs


I have not seen an error in filter.

I had issues in, but not posted to the list:

=
Building module scripting
=

and

=
Building module sc
=

restart did work around all issue except on Cui. There I commented the 
problematic build lines, and the build went on.


I have now a test version, guild finished some minutes ago. I think the 
quality is enough for testing the python module.



I would suspect then some error in the dependency logic, which 
strengthen my whish for less logic in build file, more


generators. Basically more KISS during build.



Am 24.04.20 um 07:06 schrieb Damjan Jovanovic:

On Fri, Apr 24, 2020 at 5:18 AM Peter Kovacs  wrote:


Hello all,

Build broke again, this time with Following Output:

 =
 Building module vbahelper
 =

 Entering /home/legine/workspace/AOO/gitbox/main/vbahelper/prj

 cd .. && make -s -r -j1   && make -s -r deliverlog
 [ info  ALL ] LinkTarget Library/libmsfilter.so not defined:
 Assuming headers to be there!
 [ build PKG ] vbahelper_inc
 [ build CXX ] vbahelper/source/msforms/service
 [ build CXX ] vbahelper/source/msforms/vbabutton
 [ build CXX ] vbahelper/source/msforms/vbacheckbox
 [ build CXX ] vbahelper/source/msforms/vbacombobox
 [ build CXX ] vbahelper/source/msforms/vbacontrol
 [ build CXX ] vbahelper/source/msforms/vbacontrols
 [ build CXX ] vbahelper/source/msforms/vbaframe
 [ build CXX ] vbahelper/source/msforms/vbaimage
 [ build CXX ] vbahelper/source/msforms/vbalabel
 [ build CXX ] vbahelper/source/msforms/vbalistbox
 [ build CXX ] vbahelper/source/msforms/vbalistcontrolhelper
 [ build CXX ] vbahelper/source/msforms/vbamultipage
 [ build CXX ] vbahelper/source/msforms/vbanewfont
 [ build CXX ] vbahelper/source/msforms/vbapages
 [ build CXX ] vbahelper/source/msforms/vbaprogressbar
 [ build CXX ] vbahelper/source/msforms/vbaradiobutton
 [ build CXX ] vbahelper/source/msforms/vbascrollbar
 [ build CXX ] vbahelper/source/msforms/vbaspinbutton
 [ build CXX ] vbahelper/source/msforms/vbasystemaxcontrol
 [ build CXX ] vbahelper/source/msforms/vbatextbox
 [ build CXX ] vbahelper/source/msforms/vbatogglebutton
 [ build CXX ] vbahelper/source/msforms/vbauserform
 [ build DEP ] LNK:Library/msforms.uno.so
 [ build CXX ] vbahelper/source/vbahelper/collectionbase
 [ build CXX ] vbahelper/source/vbahelper/vbaapplicationbase

/home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:
 fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory
 compilation terminated.
 [ build CXX ] vbahelper/source/vbahelper/vbaapplicationbase

/home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:
 fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory
 compilation terminated.
 /home/legine/workspace/AOO/gitbox/main/solenv/gbuild/Library.mk:48:
 *** gb_Deliver_deliver: file does not exist in solver, and cannot be
 delivered:
 /home/legine/workspace/AOO/gitbox/main/solver/450/
unxlngx6.pro/lib/libmsfilter.so.
 Stop.
 dmake:  Error code 2, while making 'all'

I guess this is a dependency Issue?

[ info  ALL ] LinkTarget Library/libmsfilter.so not defined: Assuming
headers to be there!

And

/home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:

fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory

and

/home/legine/workspace/AOO/gitbox/main/vbahelper/source/vbahelper/vbaapplicationbase.cxx:41:43:

fatal error: filter/msfilter/msvbahelper.hxx: No such file or directory

sounds like some idl has not been executed. I guess if someone is lucky
then some other build module does this.


I try to just do a rerun, and cross fingers it will pass. Inn the
meantime How do I check dependencies?

Thanks


All the Best

Peter



main/vbahelper/prj/build.lst already lists filter as a dependency. It
sounds like the filter module failed to build?

Damjan



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

Re: Update to python-2.17

2020-04-23 Thread Peter Kovacs


Hi all,


My test build has been successful and I was able to execute a python code.

This afternoon I hope I can push the changes for the migration to github 
for review.



All the best

Peter

Am 23.04.20 um 15:24 schrieb Matthias Seidel:

Hi Jim,

Am 23.04.20 um 15:21 schrieb Jim Jagielski:

On Apr 23, 2020, at 8:50 AM, Matthias Seidel  wrote:

Hi Jim,

Am 23.04.20 um 13:42 schrieb Jim Jagielski:

I agree. We should ensure that all works w/ 2.7.18 since it is the last of the Python 
2.7s... even if it means we "fix" AOO to work with it, we should simply 
baseline that version.

In trunk and AOO42X we are already on 2.7.17. No problems so far.

Yeah, I think in trunk and AOO42X we should just go w/ 2.7.18... Bite the 
bullet now.

I really don't expect problems here. Let's see what Peter can say about
his test build.

Matthias


But in 4.1.7 we still ship 2.7.6 (?).

I agree that we don't mess w/ 4.1.X


Regards,

Matthias


On Apr 21, 2020, at 7:56 AM, Matthias Seidel  wrote:

Hi all,

The final Python 2.7.18 is out:

https://www.python.org/downloads/release/python-2718/

I would expect no major changes to 2.7.17, so we could probably update
to that version?

Regards,

   Matthias

Am 02.01.20 um 03:30 schrieb Pedro Giffuni:

Hello AOO devs and best wishes for the New Year!

Well ... time has passed and Python 2 is now deprecated!

I have a patch here to update AOO 4.2's version of Python to the latest
(perhaps last) release in that line:

http://people.apache.org/~pfg/patches/patch-python-2.17.diff

This is a remake of the previous update that I had made for
cpython-2.16, but which no one tested ! I currently lack an AOO setup
with git so please someone else will have to test and commit.

On the near term, we really should update to Python 3, but that will be
challenging for the build system since it requires a newer version of
the MS compiler.

Building with an external python is also currently broken for python
versions >= 3.6.

Regards,

Pedro.


-
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



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

Re: Update to python-2.17

Re: Update to python-2.17

Re: Update to python-2.17

Re: Update to python-2.17

Re: Update to python-2.17

Re: Update to python-2.17

Re: about build environment development

Re: about build environment development

Re: about build environment development

Re: about build environment development

Problem building Cui in Trunk

Issue in vbahelper

Issue in desktop?

Re: Problem building Cui in Trunk

Re: Problem building Cui in Trunk

Re: Issue in vbahelper

Re: Issue in vbahelper

Re: Update to python-2.17

18 matches

Site Navigation

Mail list logo

Footer information