Send desktop-devel-list mailing list submissions to
desktop-devel-list gnome org
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
or, via email, send a message with subject or body 'help' to
desktop-devel-list-request gnome org
You can reach the person managing the list at
desktop-devel-list-owner gnome org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of desktop-devel-list digest..."
Today's Topics:
1. Re: Equivalent of recursive make with meson/ninja?
(Tim-Philipp M?ller)
2. Re: Help building Gstreamer 1.10 (Sam Thursfield)
3. Re: Equivalent of recursive make with meson/ninja?
(S?bastien Wilmet)
4. Re: Equivalent of recursive make with meson/ninja?
(Nirbheek Chauhan)
5. Re: Help building Gstreamer 1.10 (Sebastian Geiger (Lanoxx))
6. Re: Equivalent of recursive make with meson/ninja?
(S?bastien Wilmet)
----------------------------------------------------------------------
Message: 1
Date: Sat, 11 Feb 2017 11:54:40 +0000
From: Tim-Philipp M?ller <t i m zen co uk>
To: desktop-devel-list gnome org
Subject: Re: Equivalent of recursive make with meson/ninja?
Message-ID: <1486814080 8973 1 camel zen co uk>
Content-Type: text/plain; charset="UTF-8"
On Sat, 2017-02-11 at 12:31 +0100, S?bastien Wilmet wrote:
Hi S?bastien,
With the Autotools, recursive make is very convenient to re-build
only the stuff present in a sub-directory.
And with builddir == srcdir, it's convenient to do things like:
$ cd src/
$ make
$ touch file-that-i-modified.c
$ make
With meson/ninja, everything will end up in one single build.ninja file
(the equivalent to a Makefile).
You'd just do
touch foo.c
ninja
and it will only recompile/relink the bits that have changed, and
nothing else. It will be very very fast in most cases.
You can also do:
touch foo.c
ninja?-C ../build
if you prefer to be in the source dir.
If you haven't got a full build yet and only want to build a single
target without building more than absolutely needed you can also just
do
ninja -C ../build src/libfoobar.so.1.2.3
or somesuch (tab completion for targets should just work if you have
the right bits installed), but I'd expect that the normal use case is
that you do a full build and then just rebuild when things change.
You'll also notice that 'ninja' is near-instantaneous if there are no
changes, compared to recursive make which can take tens of seconds to
do nothing in that case. (Just as a data point, why the recursive ninja
thing is not really needed.)
I've tried this command in a project using meson:
```
$ meson .
Error during basic setup:
Source and build directories must not be the same. Create a pristine
build directory.
```
So meson doesn't support builddir == srcdir. This is a no-go for me.
That is correct, and unlikely to change, as I understand it.
For me it was also a bit annoying/hasslesome at the beginning, but I
got used to it very quickly, and it has many advantages too.
And I suppose meson/ninja doesn't support recursive ninja either (and
anyway recursive ninja with builddir != srcdir would not be
convenient).
Recursive ninja doesn't really make sense the way meson/ninja work, and
it's also not needed for what you want to do. Meson supports 'recursive
meson.build' (which is the both-in-one equivalent of configure.ac +
Makefile.am) though.
Cheers
-Tim
------------------------------
Message: 2
Date: Sat, 11 Feb 2017 12:28:31 +0000
From: Sam Thursfield <ssssam gmail com>
To: "Sebastian Geiger (Lanoxx)" <lanoxx gmx net>
Cc: desktop-devel-list <desktop-devel-list gnome org>
Subject: Re: Help building Gstreamer 1.10
Message-ID:
<CAGDGXw7Hx7ucDPn8UaMkFBBKr1ZVk4mumeH5DD3GqWk8tnRN6w mail gmail com>
Content-Type: text/plain; charset=UTF-8
Hi Lanoxx
On 2/11/17, Sebastian Geiger (Lanoxx) <lanoxx gmx net> wrote:
Hi,
I was trying to build gstreamer 1.10 today with jhbuild using the 3.22
module set, and I got the following error:
...
I've seen problems like this before which were caused by: a new symbol
being added in the source tree, an older version of the library being
installed, and the g-ir-scanner linking stuff against the old version
that is installed.
If 'gst_element_message_full_with_details' and
'gst_make_element_message_details' were recently added then that's
probably what's happening here.
To work around the issue you can do `make uninstall` in your
/home/user/Documents/Code/jh-gnome-checkout/gstreamer/ directory, then
try jhbuild again. The g-ir-scanner should now be forced to link
against the new libraries in the source tree.
This is an annoying bug, I'm not sure what causes it. Possibly some
issue in the GI/Autotools integration.
Sam
------------------------------
Message: 3
Date: Sat, 11 Feb 2017 14:02:19 +0100
From: S?bastien Wilmet <swilmet gnome org>
To: desktop-devel-list gnome org
Subject: Re: Equivalent of recursive make with meson/ninja?
Message-ID: <20170211130219 GA12490 gamma lan>
Content-Type: text/plain; charset=iso-8859-1
On Sat, Feb 11, 2017 at 11:54:40AM +0000, Tim-Philipp M?ller wrote:
With meson/ninja, everything will end up in one single build.ninja file
(the equivalent to a Makefile).
You'd just do
touch foo.c
ninja
In two different terminal tabs though.
and it will only recompile/relink the bits that have changed, and
nothing else. It will be very very fast in most cases.
It'll also relink all the tests and rebuild the docs (GTK-Doc is very
slow).
You can also do:
touch foo.c
ninja?-C ../build
if you prefer to be in the source dir.
Too long to type.
If you haven't got a full build yet and only want to build a single
target without building more than absolutely needed you can also just
do
ninja -C ../build src/libfoobar.so.1.2.3
or somesuch (tab completion for targets should just work if you have
the right bits installed), but I'd expect that the normal use case is
that you do a full build and then just rebuild when things change.
Yes I always do a full build first. autogen.sh/configure takes a lot of
time compared to meson, but once the full build is done, I just run make
commands which is fast enough.
You'll also notice that 'ninja' is near-instantaneous if there are no
changes, compared to recursive make which can take tens of seconds to
do nothing in that case. (Just as a data point, why the recursive ninja
thing is not really needed.)
What I don't like to do is to scroll up the build output to see the
warnings I'm interested in.
--
S?bastien
------------------------------
Message: 4
Date: Sat, 11 Feb 2017 19:03:01 +0530
From: Nirbheek Chauhan <nirbheek chauhan gmail com>
To: desktop-devel-list <desktop-devel-list gnome org>
Subject: Re: Equivalent of recursive make with meson/ninja?
Message-ID:
<CADqQcK6SK8Y74q5VNuC-S+GUXxVio8VYW_=0oJ39nvKju0Mthw mail gmail com>
Content-Type: text/plain; charset="utf-8"
On 11-Feb-2017 18:32, "S?bastien Wilmet" <swilmet gnome org> wrote:
and it will only recompile/relink the bits that have changed, and
nothing else. It will be very very fast in most cases.
It'll also relink all the tests and rebuild the docs (GTK-Doc is very
slow).
Fwiw, it won't rebuild the docs since that is done at install time, not at
compile time. It also won't relink all the tests if you specify a target
(an executable, library, etc) to build. You can also rebuild a specific
file by specifying the corresponding .o file, and I'm sure that can be made
more convenient with a wrapper tool.
I think your use-case can even be improved by writing such a tool that will
rebuild only a specific file. This would actually be faster than make even
because it wouldn't relink anything in that directory unless you want it
to.
Would you like to take a shot at it? It's really simpler than it might
seem. Just a matter of reading the compiler db (json file) and calling
ninja with the right argument. :)
IMO this is one of the major advantages of Meson. It actually provides an
API that you can use to support and even improve your custom workflows.
Cheers,
Nirbheek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.gnome.org/archives/desktop-devel-list/attachments/20170211/6620e151/attachment.html>
------------------------------
Message: 5
Date: Sat, 11 Feb 2017 14:53:53 +0100
From: "Sebastian Geiger (Lanoxx)" <lanoxx gmx net>
To: desktop-devel-list <desktop-devel-list gnome org>
Subject: Re: Help building Gstreamer 1.10
Message-ID: <8119d619-b03f-3b9a-8a99-c3fbd3a01b0d gmx net>
Content-Type: text/plain; charset=utf-8
Hi Sam,
thanks for the quick answer, unfortunately make uninstall did not
resolve the issue. When I searched for files with gstreamer in their
name or path I still found a lot of files. In the end I removed several
header files and so files related to gstreamer and that solved the issue.
Could this be related to the autotools build setup? Is there a way to
fix it?
Cheers
Sebastian
On 11/02/17 13:28, Sam Thursfield wrote:
Hi Lanoxx
On 2/11/17, Sebastian Geiger (Lanoxx) <lanoxx gmx net> wrote:
Hi,
I was trying to build gstreamer 1.10 today with jhbuild using the 3.22
module set, and I got the following error:
...
I've seen problems like this before which were caused by: a new symbol
being added in the source tree, an older version of the library being
installed, and the g-ir-scanner linking stuff against the old version
that is installed.
If 'gst_element_message_full_with_details' and
'gst_make_element_message_details' were recently added then that's
probably what's happening here.
To work around the issue you can do `make uninstall` in your
/home/user/Documents/Code/jh-gnome-checkout/gstreamer/ directory, then
try jhbuild again. The g-ir-scanner should now be forced to link
against the new libraries in the source tree.
This is an annoying bug, I'm not sure what causes it. Possibly some
issue in the GI/Autotools integration.
Sam
------------------------------
Message: 6
Date: Sat, 11 Feb 2017 15:56:24 +0100
From: S?bastien Wilmet <swilmet gnome org>
To: desktop-devel-list gnome org
Subject: Re: Equivalent of recursive make with meson/ninja?
Message-ID: <20170211145624 GB12490 gamma lan>
Content-Type: text/plain; charset=iso-8859-1
On Sat, Feb 11, 2017 at 07:03:01PM +0530, Nirbheek Chauhan wrote:
On 11-Feb-2017 18:32, "S?bastien Wilmet" <swilmet gnome org> wrote:
It'll also relink all the tests and rebuild the docs (GTK-Doc is very
slow).
Fwiw, it won't rebuild the docs since that is done at install time, not at
compile time.
That is a strange thing to do, building something at install time.
I often do:
$ cd docs/
$ make clean
$ make
to see if there are any warnings. If it's mixed up with install output,
it's far less convenient.
And thanks to builddir == srcdir, I often do:
$ cd docs/reference/
$ vi -o <gtk-doc-section-file> <gtk-doc-unused-file>
to move the symbols from the 'unused' file to the section file.
<gtk-doc-section-file> is in scrdir while <gtk-doc-unused-file> is in
builddir. The names of those files are different for each project
(although it's probably possible to use globs).
But these are just examples, `touch file.c && make` was another example.
I probably do other similar things (more rarely, without even being
aware of it) thanks to recursive make and builddir == srcdir. Basically
each time I want to open a built file, I'm usually already in the good
directory.
It also won't relink all the tests if you specify a target
(an executable, library, etc) to build. You can also rebuild a specific
file by specifying the corresponding .o file, and I'm sure that can be made
more convenient with a wrapper tool.
I think your use-case can even be improved by writing such a tool that will
rebuild only a specific file. This would actually be faster than make even
because it wouldn't relink anything in that directory unless you want it
to.
Would you like to take a shot at it? It's really simpler than it might
seem. Just a matter of reading the compiler db (json file) and calling
ninja with the right argument. :)
IMO this is one of the major advantages of Meson. It actually provides an
API that you can use to support and even improve your custom workflows.
Mmh, yes, maybe.
--
S?bastien
------------------------------
Subject: Digest Footer
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
------------------------------
End of desktop-devel-list Digest, Vol 154, Issue 9
**************************************************
