Re: Meson: yet another build system

[Peter Kovacs]

On 05.12.2016 23:39, Louis Suárez-Potts wrote:



Porting to Meson will not be any easier than porting to gbuild. Writing
gbuild code becomes easy with practice. *Understanding* dmake / build.lst /
d.lst is hard...


So you are now a fan of gbuild? ;).

Moving python would be a huge step forward towards getting rid of dmake
as it seems to be required for any alternative build system (other than gbuild 
which of course would require it to build with gbuild anyways).

I presume that LibreOffice also uses the same build system? Would they be 
interested in using Meson, you think? Note, I hope that any notion of invidious 
difference (e.g., competitive and implicitly jealous differentiation) plays no 
role here in the larger goal of making building OpenOffice more feasible for 
more.
Louis
Interesting Idea. Never thought of that. It seems like they already 
moved away from dmake.

https://wiki.documentfoundation.org/Development/BuildingOnLinux

I would have been surprised if the Distros would not have done the 
change. But it could help us, couldnt it?



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

Re: Meson: yet another build system

[Peter Kovacs]

On 05.12.2016 22:43, Damjan Jovanovic wrote:

Please elaborate?

I experience different issues.

1)
In file included from /main/udm/source/html/htmlitem.cxx:24:0:
../inc/precomp.h:32:30: fatal error: cosv/csv_precomp.h: No such file or
directory
  #include 

2) libgcc_s.so.1 copy gets corrupted at copy from time to time. I fix the
error by running a script that replaces the file with a softlink.

3) basebmp has issues:

main/basebmp/inc/basebmp/packedpixeliterator.hxx:86:23: error: left
operand of shift expression '(-1 << 1)' is negative [-fpermissiv]
main/basebmp/inc/basebmp/packedpixeliterator.hxx:80:10: error: enumerator
value for 'bit_mask' is not an integer constant enum {

It finally breaks with
make: *** No rule to make target '/main/solver/420/un
xlngx6.pro/workdir/CxxObject/basebmp/source/bitmapdevice.o', needed by
'/main/solver/420/unxlngx6.pro/workdir/LinkTarget/
Library/libbasebmp.so'. Stop.

4) icu breaks also with *** No rule to make target

5) if the build breaks lets say in basebmp, and I switch shells and start
build --all:basebmp it starts running again. But I have the feeling that it
does not maintain the order it had before. So there is an inconcitency, if
you stop after a break. shut down your console and start all over again.


Since I am on Arch Linux, wich is in nature quite different to traditional
distros I would not rule side effects out of my distro. However I dont have
a clue where to start looking, or what I should expect from the build
system.


All the best
Peter


Interesting.

Which version are you compiling? I don't see the "-1 << 1" in my
basebmp/inc/basebmp/packedpixeliterator.hxx on SVN trunk.

Damjan


I try to build trunc. Updated it on saturday last time.

Peter


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

Re: Meson: yet another build system

[Louis Suárez-Potts]

> On 05 Dec 2016, at 11:32, Pedro Giffuni  wrote:
> 
>> Objective C? Yacc? Cygwin? Custom compiler flags to disable C++ exception
>> handling, build some files with optimizations disabled?
>> 
>> Our build systems are not our biggest problem. Meson, or SCons, or others,
>> could be good if we were starting a new project. We aren't. We are
>> maintaining one we poorly understand.
>> 
> 
> I agree the build system is not our biggest problem.
> 
>> Porting to Meson will not be any easier than porting to gbuild. Writing
>> gbuild code becomes easy with practice. *Understanding* dmake / build.lst /
>> d.lst is hard...
>> 
> 
> So you are now a fan of gbuild? ;).
> 
> Moving python would be a huge step forward towards getting rid of dmake
> as it seems to be required for any alternative build system (other than 
> gbuild which of course would require it to build with gbuild anyways).

I presume that LibreOffice also uses the same build system? Would they be 
interested in using Meson, you think? Note, I hope that any notion of invidious 
difference (e.g., competitive and implicitly jealous differentiation) plays no 
role here in the larger goal of making building OpenOffice more feasible for 
more.
Louis

> 
>> I've spend the last day trying to port several more modules to gbuild. I've
>> succeeded with main/fileaccess, main/io and main/package, but ran into
>> walls with main/rdbmaker and main/store. Dmake apparently has ways to name
>> libraries that gbuild can neither produce nor find (eg. libstore.so.3,
>> libreg.so.3). These culprits use the evil UNIXVERSIONNAMES setting which
>> generates such names:
>> 
>> cppu
>> cppuhelper
>> jvmaccess
>> jvmfwk
>> registry
>> salhelper
>> sal
>> store
>> 
>> 
> 
> Jikes.
> 
> 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: Meson: yet another build system

[Damjan Jovanovic]

On Mon, Dec 5, 2016 at 11:19 PM, Peter Kovacs  wrote:

>
>
> On 05.12.2016 21:59, Damjan Jovanovic wrote:
>
>> On Mon, Dec 5, 2016 at 8:46 PM, Peter Kovacs  wrote:
>>
>>
>>> On 05.12.2016 17:32, Pedro Giffuni wrote:
>>>
>>> Objective C? Yacc? Cygwin? Custom compiler flags to disable C++ exception

> handling, build some files with optimizations disabled?
>
> Our build systems are not our biggest problem. Meson, or SCons, or
> others,
> could be good if we were starting a new project. We aren't. We are
> maintaining one we poorly understand.
>
>
> I agree the build system is not our biggest problem.

 My build Problems are substantial. It blocks all other activities I want
>>> to do.
>>>
>>> Please elaborate?
>>
>> I experience different issues.
> 1)
> In file included from /main/udm/source/html/htmlitem.cxx:24:0:
> ../inc/precomp.h:32:30: fatal error: cosv/csv_precomp.h: No such file or
> directory
>  #include 
>
> 2) libgcc_s.so.1 copy gets corrupted at copy from time to time. I fix the
> error by running a script that replaces the file with a softlink.
>
> 3) basebmp has issues:
>
> main/basebmp/inc/basebmp/packedpixeliterator.hxx:86:23: error: left
> operand of shift expression '(-1 << 1)' is negative [-fpermissiv]
> main/basebmp/inc/basebmp/packedpixeliterator.hxx:80:10: error: enumerator
> value for 'bit_mask' is not an integer constant enum {
>
> It finally breaks with
> make: *** No rule to make target '/main/solver/420/un
> xlngx6.pro/workdir/CxxObject/basebmp/source/bitmapdevice.o', needed by
> '/main/solver/420/unxlngx6.pro/workdir/LinkTarget/
> Library/libbasebmp.so'. Stop.
>
> 4) icu breaks also with *** No rule to make target
>
> 5) if the build breaks lets say in basebmp, and I switch shells and start
> build --all:basebmp it starts running again. But I have the feeling that it
> does not maintain the order it had before. So there is an inconcitency, if
> you stop after a break. shut down your console and start all over again.
>
>
> Since I am on Arch Linux, wich is in nature quite different to traditional
> distros I would not rule side effects out of my distro. However I dont have
> a clue where to start looking, or what I should expect from the build
> system.
>
>
> All the best
> Peter
>

Interesting.

Which version are you compiling? I don't see the "-1 << 1" in my
basebmp/inc/basebmp/packedpixeliterator.hxx on SVN trunk.

Damjan

Re: Meson: yet another build system

[Peter Kovacs]

On 05.12.2016 21:59, Damjan Jovanovic wrote:

On Mon, Dec 5, 2016 at 8:46 PM, Peter Kovacs  wrote:



On 05.12.2016 17:32, Pedro Giffuni wrote:


Objective C? Yacc? Cygwin? Custom compiler flags to disable C++ exception

handling, build some files with optimizations disabled?

Our build systems are not our biggest problem. Meson, or SCons, or
others,
could be good if we were starting a new project. We aren't. We are
maintaining one we poorly understand.



I agree the build system is not our biggest problem.


My build Problems are substantial. It blocks all other activities I want
to do.


Please elaborate?


I experience different issues.
1)
In file included from /main/udm/source/html/htmlitem.cxx:24:0:
../inc/precomp.h:32:30: fatal error: cosv/csv_precomp.h: No such file or 
directory

 #include 

2) libgcc_s.so.1 copy gets corrupted at copy from time to time. I fix 
the error by running a script that replaces the file with a softlink.


3) basebmp has issues:

main/basebmp/inc/basebmp/packedpixeliterator.hxx:86:23: error: left 
operand of shift expression '(-1 << 1)' is negative [-fpermissiv]
main/basebmp/inc/basebmp/packedpixeliterator.hxx:80:10: error: 
enumerator value for 'bit_mask' is not an integer constant enum {


It finally breaks with
make: *** No rule to make target 
'/main/solver/420/unxlngx6.pro/workdir/CxxObject/basebmp/source/bitmapdevice.o', 
needed by 
'/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libbasebmp.so'. 
Stop.


4) icu breaks also with *** No rule to make target

5) if the build breaks lets say in basebmp, and I switch shells and 
start build --all:basebmp it starts running again. But I have the 
feeling that it does not maintain the order it had before. So there is 
an inconcitency, if you stop after a break. shut down your console and 
start all over again.



Since I am on Arch Linux, wich is in nature quite different to 
traditional distros I would not rule side effects out of my distro. 
However I dont have a clue where to start looking, or what I should 
expect from the build system.


All the best
Peter

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

Re: Meson: yet another build system

[Damjan Jovanovic]

On Mon, Dec 5, 2016 at 8:46 PM, Peter Kovacs  wrote:

>
>
> On 05.12.2016 17:32, Pedro Giffuni wrote:
>
>> Objective C? Yacc? Cygwin? Custom compiler flags to disable C++ exception
>>> handling, build some files with optimizations disabled?
>>>
>>> Our build systems are not our biggest problem. Meson, or SCons, or
>>> others,
>>> could be good if we were starting a new project. We aren't. We are
>>> maintaining one we poorly understand.
>>>
>>>
>> I agree the build system is not our biggest problem.
>>
> My build Problems are substantial. It blocks all other activities I want
> to do.
>

Please elaborate?

Re: Meson: yet another build system

[Peter Kovacs]

On 05.12.2016 17:32, Pedro Giffuni wrote:
Objective C? Yacc? Cygwin? Custom compiler flags to disable C++ 
exception

handling, build some files with optimizations disabled?

Our build systems are not our biggest problem. Meson, or SCons, or 
others,

could be good if we were starting a new project. We aren't. We are
maintaining one we poorly understand.



I agree the build system is not our biggest problem.
My build Problems are substantial. It blocks all other activities I want 
to do.



Porting to Meson will not be any easier than porting to gbuild. Writing
gbuild code becomes easy with practice. *Understanding* dmake / 
build.lst /

d.lst is hard...



So you are now a fan of gbuild? ;).

Moving python would be a huge step forward towards getting rid of dmake
as it seems to be required for any alternative build system (other 
than gbuild which of course would require it to build with gbuild 
anyways).

What do you mean by this?

All the best
Peter

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

Re: Meson: yet another build system

[Pedro Giffuni]

Objective C? Yacc? Cygwin? Custom compiler flags to disable C++ exception
handling, build some files with optimizations disabled?

Our build systems are not our biggest problem. Meson, or SCons, or others,
could be good if we were starting a new project. We aren't. We are
maintaining one we poorly understand.



I agree the build system is not our biggest problem.


Porting to Meson will not be any easier than porting to gbuild. Writing
gbuild code becomes easy with practice. *Understanding* dmake / build.lst /
d.lst is hard...



So you are now a fan of gbuild? ;).

Moving python would be a huge step forward towards getting rid of dmake
as it seems to be required for any alternative build system (other than 
gbuild which of course would require it to build with gbuild anyways).



I've spend the last day trying to port several more modules to gbuild. I've
succeeded with main/fileaccess, main/io and main/package, but ran into
walls with main/rdbmaker and main/store. Dmake apparently has ways to name
libraries that gbuild can neither produce nor find (eg. libstore.so.3,
libreg.so.3). These culprits use the evil UNIXVERSIONNAMES setting which
generates such names:

cppu
cppuhelper
jvmaccess
jvmfwk
registry
salhelper
sal
store




Jikes.

Pedro.



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

Re: Meson: yet another build system

[Damjan Jovanovic]

Objective C? Yacc? Cygwin? Custom compiler flags to disable C++ exception
handling, build some files with optimizations disabled?

Our build systems are not our biggest problem. Meson, or SCons, or others,
could be good if we were starting a new project. We aren't. We are
maintaining one we poorly understand.

Porting to Meson will not be any easier than porting to gbuild. Writing
gbuild code becomes easy with practice. *Understanding* dmake / build.lst /
d.lst is hard...

I've spend the last day trying to port several more modules to gbuild. I've
succeeded with main/fileaccess, main/io and main/package, but ran into
walls with main/rdbmaker and main/store. Dmake apparently has ways to name
libraries that gbuild can neither produce nor find (eg. libstore.so.3,
libreg.so.3). These culprits use the evil UNIXVERSIONNAMES setting which
generates such names:

cppu
cppuhelper
jvmaccess
jvmfwk
registry
salhelper
sal
store


Damjan


On Tue, Nov 29, 2016 at 8:52 PM, Pedro Giffuni  wrote:

> http://mesonbuild.com/
>
>
>  Features
>
>  * multiplatform support for Linux, OSX, Windows, Gcc, Clang, Visual
>Studio and others
>  * supported languages include C, C++, Fortran, Java, Rust
>  * build definitions in a very readable and user friendly non-turing
>complete DSL
>  * cross compilation for many operating systems as well as bare metal
>  * optimized for extremely fast full and incremental builds without
>sacrificing correctness
>  * built-in multiplatform dependency provider that works together with
>distro packages
>  * fun!
>
>