meson-devel — Development discussion

Re: [Meson-devel] Meson can now compile Qt Creator

[Jussi P. <jpa...@gm...>]

On Wed, Jun 25, 2014 at 8:44 AM, james <ja...@ma...> wrote:

 Tkanks  Now the outputs are going to be a mix of file types - one or more
> source files and an object type.
>

This email is to let all subscribers know that Meson has moved from
Sourceforge into Github. The appropriate links are:

Home page: http://jpakkane.github.io/meson
Email list: https://groups.google.com/d/forum/mesonbuild

I will write a proper answer to this question to the new mailing list.

Thanks, see you all on the new site.

Re: [Meson-devel] Meson can now compile Qt Creator

[james <ja...@ma...>]

On 14/05/2014 08:25, Jussi Pakkanen wrote:
> ...
>
>     The one that interests me happens to be:
>
>     IDL file (containing ODL) (tool: midl)
>      -> TLB file (referenced from RC file, tool: rc)
>       -> RES file (tool: cvtres)
>        -> OBJ file
>
>     which is a chain used in building COM DLLs.
>
>
> Currently Meson has the limitation that you can't use the output of 
> generated source as input to a second generator command. You can work 
> around this by writing a simple script that does all your generator 
> steps in one go and then call that. So something like this:
>
> mygen = find_program('myscript.bat')
> gen  =  generator(myget,
>   outputs   :  ['@BASENAME@.TLB', '@BASENAME@.RES', '@BASENAME@.obj'],
>   arguments  :  ['@INPUT@',  '@BUILD_DIR@'])
>
Tkanks  Now the outputs are going to be a mix of file types - one or 
more source files and an object type.

It may also be necessary to try to convince ninja to use a generated 
dependency file.

I see that we specify objects specifically:

|exe = executable('myexe', 'source.cpp', objects : 'third_party_object.o')|

and the a generator output list can be gathered and used like this:

gen_src  =  gen.process('input1.idl',  'input2.idl')
executable('program',  'main.c',  gen_src)

If gen_src is a mix of objects and sources, how can I pass it to 
'executable'?  In this case I'd have an obj file as a result of cvtres, 
and the generated COM server implementation files.

Will the program I define for the generator be invoked by ninja with 
dependency generator options determined by the primary C++ compiler 
type?  Can I influence it?

James

Re: [Meson-devel] Meson can now compile Qt Creator

[Jussi P. <jpa...@gm...>]

On Wed, May 14, 2014 at 8:39 AM, james <ja...@ma...> wrote:

Does this mean that meson will gain understanding of code generation
> chains, with moc?
>

Meson already has that. See for example the manual:

https://sourceforge.net/p/meson/wiki/Generating%20sources/

It should be noted that Qt5's moc is special cased into Meson because it is
so common. This reduces the amount of boilerplate people need to write.

The one that interests me happens to be:
>
> IDL file (containing ODL) (tool: midl)
>  -> TLB file (referenced from RC file, tool: rc)
>   -> RES file (tool: cvtres)
>    -> OBJ file
>
> which is a chain used in building COM DLLs.
>

Currently Meson has the limitation that you can't use the output of
generated source as input to a second generator command. You can work
around this by writing a simple script that does all your generator steps
in one go and then call that. So something like this:

mygen = find_program('myscript.bat')

gen = generator(myget,
 outputs  : ['@BASENAME@.TLB', '@BASENAME@.RES', '@BASENAME@.obj'],
 arguments : ['@INPUT@', '@BUILD_DIR@'])

Ideally I'd like a build system that will build for 32 and 64 bit targets
> at the same time.
>

Currently this is not possible, but you can have multiple build directories
for the same source code, one for 32 and one for 64 bits.

The reason this can't be done is that I have not had to deal with this
issue personally, so I don't know what would be the best practice would be.


> There are other use cases I'm interested in too, where we
> compile-the-compiler and then run it (typically to generate code from a
> DSL).  Do you build the moc compiler as part of this?


I don't build moc but it is possible. Meson's source code has a unit test
for this, even:

https://sourceforge.net/p/meson/code/ci/master/tree/test%20cases/common/29%20pipeline/

Re: [Meson-devel] Meson can now compile Qt Creator

[james <ja...@ma...>]

Does this mean that meson will gain understanding of code generation 
chains, with moc?

The one that interests me happens to be:

IDL file (containing ODL) (tool: midl)
  -> TLB file (referenced from RC file, tool: rc)
   -> RES file (tool: cvtres)
    -> OBJ file

which is a chain used in building COM DLLs.

Ideally I'd like a build system that will build for 32 and 64 bit 
targets at the same time.

There are other use cases I'm interested in too, where we 
compile-the-compiler and then run it (typically to generate code from a 
DSL).  Do you build the moc compiler as part of this?

James

[Meson-devel] Meson can now compile Qt Creator

[Jussi P. <jpa...@gm...>]

Hi

After days and weeks of effort, Meson has finally reached the point where
it can compile the whole of Qt Creator. We are extremely happy to be able
to prove that Meson can be used for these kinds of large scale projects.
Here are the numbers (on a Macbook Pro retina running Ubuntu 14/04):

- project configure time: <5 seconds
- unoptimized build time: 26 minutes
- no-op build time: 0.1 seconds
- total build steps: 4281
- build directory size: 2.1 GB
- size of build definitions: 4310 lines (12000 for Qmake, 8000 for qbs)

All libraries, plugins, and binaries are compiled but there are some
deficiencies:

- only one unit test is built and can be run, adding others would be just a
question of manual labor
- plugin link definitions are probably missing things, so attempting to use
some plugins will lead to missing symbols
- the actual executable won't start because Meson puts its build artifacts
into a different place than qmake so the main executable won't find them
- only works on Linux
- can not be installed
- lots of other things are probably broken

If you wish to try it yourself, you need the following:

- Meson from trunk: https://sourceforge.net/p/meson/code/ci/master/tree/
- mesonified Qt Creator from here:
https://qt.gitorious.org/qt-creator/qt-creator-meson
- Ninja and Qt5 from your distribution's packages

To build it yourself do this:

cd into_qtcreator
mkdir buildmeson
cd buildmeson
/path/to/meson.py ..
ninja (or ninja-build on Fedora)

This should provide you with a fully built but
so-broken-it-refuses-to-start Qt Creator. :)

Enjoy,

Re: [Meson-devel] Use of sub directories

[Jussi P. <jpa...@gm...>]

On Sun, Jan 19, 2014 at 10:23 PM, Lars Pensjö <lar...@gm...> wrote:

I got it working for my (medium complex) project now
> (see Ephenation client<https://github.com/larspensjo/ephenation-client/blob/mesonbuild/Source/meson.build>
> ).
> I have several sub folders with source code, but so far I have only one
> main meson.build.
>

Cool. That is the largest third party Meson project I have seen thus far.


> The list of source code files is rather long, and it would be nice to
> specify a separate list for each sub directory. I am not sure how to best
> do that. I can use the subdir() command to access a local meson.build in
> each sub directory. That works, but there are some minor inconveniences:
>

A common convention is that the source in one subdirectory should provide
one unit (be it a library, executable, or something else). I do understand
that as projects get bigger, this becomes harder and harder. However if you
wish to have source from multiple subdirectories in one target, one simple
way to do it is something like this:

adir_src = ['a/one.cpp', 'a/two.cpp']
bdir_src = ['b/three.cpp', 'b/three.cpp)

executable('myexe', sources : ['main.cpp', adir_src, bdir_src])

You can create arrays of (arrays of) strings and Meson will automatically
flatten them for you.

I might add something that works like include_directories, that is, it
remembers the path to sources and you can then pass these around. I need to
think a bit how that is best implemented.

The obvious follow up question to this is "Couldn't I just glob the source
files?". The answer to this is, unfortunately, no. One of Meson's main
design goals is that it must be fast and scalable. The reason Ninja works
so fast is that it knows exactly which files to inspect. If a build target
is defined in terms of a globbing operation, then it would need to traverse
the full contents of the source tree (or parts thereof) on every
invocation. There is no way to make that fast.


>
> An alternative solution is to use subproject() and static libraries. But
> these sub projects will not get access to states defined by the main
> project, which is a problem to me as they are really part of the same
> project.
>

You don't need subprojects for static libraries. Subproject is designed for
one very specific goal. Suppose you have a third party library libfoo (that
builds with Meson) that you want to use. On Linux you would use pkg-config
but on Windows you can't. On Windows you would put the full upstream
release source in a subdirectory and call subproject(). Then you could grab
the output targets (usually static/shared libraries) and use them as if
they were a part of your own project. But you should only need to use it on
third party libraries, not your own code.

If you want to build your subdirectories as static libraries, you can
totally do that with subdir(). So something like this.

In subdir a:

stat_a = static_library('stata', 'foo.cpp', 'bar.cpp')

In subdir b:

stat_b = static_library('statb', 'baz.cpp', 'bof.cpp')

and then in your toplevel dir you would do:

executable('myexe', 'main.cpp', link_with : [stat_a, stat_b])

Just be aware that because of the way static linking works, if you have a
circular dependency between stat_a and stat_b you will be in a world of
pain.

[Meson-devel] Use of sub directories

[Lars P. <lar...@gm...>]

I got it working for my (medium complex) project now
 (see Ephenation
client<https://github.com/larspensjo/ephenation-client/blob/mesonbuild/Source/meson.build>
).

I have several sub folders with source code, but so far I have only one
main meson.build.


The list of source code files is rather long, and it would be nice to
specify a separate list for each sub directory. I am not sure how to best
do that. I can use the subdir() command to access a local meson.build in
each sub directory. That works, but there are some minor inconveniences:

   1. Each local meson.build will have to create a global variable that
   contains a list of file names. This global variable then has to be
   referred to from the main meson.build.

   2. The list of local files has to include the name of the sub directory.

An alternative solution is to use subproject() and static libraries. But
these sub projects will not get access to states defined by the main
project, which is a problem to me as they are really part of the same
project.

Best regards,
     Lars Pensjö

Re: [Meson-devel] Include directories

[Jussi P. <jpa...@gm...>]

On Sat, Jan 18, 2014 at 7:30 PM, Lars Pensjö <lar...@gm...> wrote:


> I have problems to get the include_directories command to work. The source
> code directory contains the sub folders contrib/glm and
> contrib/libovr/include. Doing the following:
> glm = include_directories('contrib/glm')
> libovr = include_directories('contrib/libovr/include')
> incdirs = [glm, libovr]
> ...
> executable('ephenation', sources:src, deps : deps, inc_dirs : incdirs)
>

The wiki page had a typo. "inc_dirs" should be "include_dirs". The wiki is
fixed, sorry about that.


> If I tried to specify an illegal directory to include_directories, there
> is no error message.
>

The code had a comment saying "FIXME, check that directories actually
exist" :). This is now fixed in trunk. Thanks for reporting.

Re: [Meson-devel] meson build system

[Jussi P. <jpa...@gm...>]

I received this query via sf's contact user box. Replying here so other
people can find this information too.

Hi,
>
> the meson project looks like a really nice thing! I was testing the meson
> project (in Mint16),
> and get the error \"ImportError: No module named \'PyQt5\'\" when I run
> the mesongui. So I did as
> follows:
>
> sudo apt-get install pyqt5-dev
>
> But still I get the same error.
>

That is the package for developing PyQT5. Meson only uses it. The package
you want (at least on Ubuntu) is python3-pyqt5.


> I need to specify a -I flag to the compiler. The old flag used in makefile
> is \"-Icontrib\", but I now
> have to specify it as \"-I../contrib\" to get the path correct when ninja
> is run in the build
> subdirectory. Is that the best way to do it? That means I have a path that
> depends on where the
> build directory is.
>

Apparently I had not written a manual page on how to use include
directories. Now there is one:

https://sourceforge.net/p/meson/wiki/Include%20directories/


> dependency(\'x11\') works, but dependency(\'pthread\') doesn\'t. Is there
> a special list of
> dependencies that can be used? If so, can I extend this list somehow?
>

Dependency currently uses pkg-config, so any package that provides a
pkg-config file will work transparently. In addition there is extra code to
deal with Qt5 and Boost. Adding more dependencies means editing the
dependencies.py source file.

In this particular case, what you want is to just link against the pthread
library. It is done like this:

ptl = find_library('pthread')
executable('pthreadtest', 'main.c', deps : ptl)

There is no special casing for threads yet. The reason for this is that I
don't really know what is the correct way to do threading related stuff on
Windows. Thus I can't commit to any Meson-specific syntax quite yet, sorry.

[Meson-devel] Meson talk at FOSDEM

[Jussi P. <jpa...@gm...>]

Hello all

My lightning talk about Meson has been accepted for presentation in FOSDEM
2014. See you there and feel free to find me and ask any questions about
Meson at any time during the conference (I don't guarantee coherent answers
at night, though).

[Meson-devel] Meson now available in packages

[Jussi P. <jpa...@gm...>]

Hello

I have written Meson packages. They are available here:

https://launchpad.net/~jpakkane/+archive/ppa/+packages

The packages are for Ubuntu raring, but should work with Saucy and possibly
also with Debian Unstable, though you might need to install python3.3 and
run Meson manually like this "python3.3 /usr/bin/meson <args>" because the
default Python3 in Debian is still 3.2.

Meson has been submitted to Debian. See details here:

http://mentors.debian.net/package/meson

Hopefully we'll get a sponsor so Meson can enter the main archive.

[Meson-devel] 0.1.0 is released

[Jussi P. <jpa...@gm...>]

Hi you all

I have just pushed out version 0.1.0. It does all the basic things a
build system needs to do, though there are definitely still some rough
edges. But as we all know, open source is all about releasing early
and often.

The most valuable thing that you can do is to try it out and then let
us know what you think. What works? What doesn't? What would you like
to see added next?

I'm probably going to start looking into an XCode project generator
next. A Visual studio backend would be great too, but I probably won't
have time do do that in the near future.

[Meson-devel] Next steps

[Jussi P. <jpa...@gm...>]

Hi

Now that Meson is released, I'd like to outline the roadmap for the
near future. These are the things that are planned currently:

1. Preserve config status on regeneration

When you regenerate a project, it destroys all existing data. Add code
to serialize this state to disk and reread it when regenerating.

2. Make Meson installable

Currently Meson only works when run from its source directory. Make it
installable so it can be packaged and thus included to distros.

3. Add coverage support

Coverage reports are an integral part of modern sw development. Meson
needs to provide those automatically.

4. Add support for code generation programs.

It is common to build an executable and then use that executable to
generate fresh source code which is then added to a target. Add
support for this functionality.