Meson: yet another build system

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Meson: yet another build system

Pedro Giffuni
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!

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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!
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Meson: yet another build system

Pedro Giffuni
In reply to this post by 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Meson: yet another build system

Damjan Jovanovic
On Mon, Dec 5, 2016 at 8:46 PM, Peter Kovacs <[hidden email]> 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?
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <svn_path>/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 <cosv/csv_precomp.h>

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
'<svn_path>/main/solver/420/unxlngx6.pro/workdir/CxxObject/basebmp/source/bitmapdevice.o',
needed by
'<svn_path>/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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Meson: yet another build system

Damjan Jovanovic
On Mon, Dec 5, 2016 at 11:19 PM, Peter Kovacs <[hidden email]> wrote:

>
>
> On 05.12.2016 21:59, Damjan Jovanovic wrote:
>
>> On Mon, Dec 5, 2016 at 8:46 PM, Peter Kovacs <[hidden email]> 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 <svn_path>/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 <cosv/csv_precomp.h>
>
> 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 '<svn_path>/main/solver/420/un
> xlngx6.pro/workdir/CxxObject/basebmp/source/bitmapdevice.o', needed by
> '<svn_path>/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
Reply | Threaded
Open this post in threaded view
|

Re: Meson: yet another build system

Louis Suárez-Potts-3
In reply to this post by Pedro Giffuni

> On 05 Dec 2016, at 11:32, Pedro Giffuni <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Meson: yet another build system

Peter Kovacs
In reply to this post by Damjan Jovanovic


On 05.12.2016 22:43, Damjan Jovanovic wrote:

> Please elaborate?
>>> I experience different issues.
>> 1)
>> In file included from <svn_path>/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 <cosv/csv_precomp.h>
>>
>> 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 '<svn_path>/main/solver/420/un
>> xlngx6.pro/workdir/CxxObject/basebmp/source/bitmapdevice.o', needed by
>> '<svn_path>/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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Meson: yet another build system

Peter Kovacs
In reply to this post by Louis Suárez-Potts-3


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: [hidden email]
For additional commands, e-mail: [hidden email]