In the commits, I note this:
On Tue, Apr 23, 2024 at 03:53:39PM -0400, Matt Turner wrote:
>[...]
> Eric Anholt (10):
> [...]
> Remove the autotools build system.
There are OSes that do not ship with Python. During an intermim
period, couldn't we provide _both_ autotools and meson?
Once more (feel free to change the name of the utility if you find a
better one):
On Sun, Apr 07, 2024 at 09:43:19PM +0200, tlaro...@kergis.com wrote:
>
> Could someone with write access accept this merge request? The utility
> is orthogonal so this can't break anything and I would like to have
>
Could someone with write access accept this merge request? The utility
is orthogonal so this can't break anything and I would like to have
this at disposal while writing meson support for modules lacking it
without having to modify the CI files (.gitlab-ci.yml) to fetch my
forked version and to
FWIW, I have added to xorg/util/modular, the POSIX.2 sh utility:
auto-meson-pc-cmp.sh
that allows to compare two directories for pc files, checking that
the same relative pathnames exist in the two dirs and that the same
named files "say" the same things, even if they don't say it the same
way
On Wed, Mar 27, 2024 at 09:00:12PM +1000, Peter Hutterer wrote:
> On Mon, Mar 25, 2024 at 11:19:49AM +0100, tlaro...@kergis.com wrote:
> > On Mon, Mar 25, 2024 at 08:07:24PM +1000, Peter Hutterer wrote:
> > > On Mon, Mar 25, 2024 at 08:36:44AM +0100, tlaro...@kergis.com wrote:
> > > > In a
On Mon, Mar 25, 2024 at 08:07:24PM +1000, Peter Hutterer wrote:
> On Mon, Mar 25, 2024 at 08:36:44AM +0100, tlaro...@kergis.com wrote:
> > In a previous mail, I proposed, when autotools and meson are both
> > provided to build a module, to not verify what they provide by simply
> > diffing the
In a previous mail, I proposed, when autotools and meson are both
provided to build a module, to not verify what they provide by simply
diffing the resulting installation directories, but to treat pkgconfig
generated *.pc files specially, by comparing them semantically and
not lexically (just
On Sat, Mar 23, 2024 at 11:02:33AM -0700, Alan Coopersmith wrote:
> On 3/23/24 09:24, tlaro...@kergis.com wrote:
> > Furthermore, for example for xcb-proto, the python interface is one
> > interface, but it is not mandatory (there is the primary C interface).
>
> The python files in xcb-proto are
The byte-compiled (version depending) files for *.py should be
generated at install time, on the target, because:
1) Python files have only sense on nodes where a python interpreter
is installed; and the byte-compilation is generated by an interpreter;
2) byte-compiled versions are not portable.
In xcb-proto, for example, there are python files that are supposed to
be byte-compiled at installation time.
There are two problems:
1) The python version to use is defined at configuration time; while,
since python is not required at "compilation" time, it would be better
to have a package
When comparing autotools vs. meson generated files, the CI currently
compares the pc files lexically, byte by byte.
This is the reason why in the current version of xorg-sgml-doctools
there is a discrepancy between the definition of what is put in the pc
file and what is indeed used as definition
Alan Coopersmith has answered concerning ${libdir}/pkgconfig vs
${datadir}/pkgconfig and this makes perfect sense.
But remains a discrepancy:
In xorg-sgml-doctools/Makefile.am we have:
pkgconfigdir = $(datadir)/pkgconfig
In xcb-proto/Makefile.am we have:
pkgconfigdir =
On Mon, Mar 04, 2024 at 07:45:16PM +0100, tlaro...@kergis.com wrote:
> [...]
> There is one thing that will have to be decided globally.
>
> For now, pkgconfig files are installed in ${datadir}/pkgconfig.
>
> But "normally", pkgconfig files have to be installed in
> ${libdir}/pkgconfig meaning
On Mon, Mar 04, 2024 at 10:41:31AM -0800, Alan Coopersmith wrote:
> On 3/4/24 01:49, tlaro...@kergis.com wrote:
> > As written in a previous mail, I'm trying to adjust meson to provide
> > the same rope as AC.
> >
> > For xorg-sgml-doctools, there was a small discrepancy if the user was
> > not
CI passed.
I have modified meson.build and added a meson_options.txt so that
with meson it is possible to set install directory with the
flexibility offered by the autotools.
Namely, autotools allows to set datadir and datarootdir. datarootdir
is for data added; datadir is used to place
On Sun, Mar 03, 2024 at 12:39:12PM -0800, Alan Coopersmith wrote:
> >
> > 1) meson.build defines:
> >
> > datarootdir = get_option('prefix') / get_option('datadir')
> > sgmlrootdir = datarootdir / 'sgml'
> >
> > and generates the pkgconfig file from the template with:
> >
> > pc_conf =
As written in a previous mail, I'm trying to adjust meson to provide
the same rope as AC.
For xorg-sgml-doctools, there was a small discrepancy if the user was
not selecting the defaults. This is easy to fix (diff attached), but I
now wonder about pkgconfig .pc files directory.
In generated
On Sun, Mar 03, 2024 at 12:39:12PM -0800, Alan Coopersmith wrote:
> On 3/3/24 12:06, tlaro...@kergis.com wrote:
> > [I'm back to working on Xorg stuff].
> >
> > When writing a meson.build, I realize that all the options settable
> > with GNU AC are not available in meson built-ins. This does mean
[I'm back to working on Xorg stuff].
When writing a meson.build, I realize that all the options settable
with GNU AC are not available in meson built-ins. This does mean
that one has to add a meson_options.txt for everything used that is
not a built-in options in meson?
I take the example of
On Fri, Feb 16, 2024 at 08:22:59PM +1000, Peter Hutterer wrote:
> On Wed, Feb 14, 2024 at 09:37:43PM +0100, tlaro...@kergis.com wrote:
> > Some meson.build, for example, have a SPDX-License-Identifier: tag,
> > where "MIT" is mentionned, applying (I think) to the file itself, and
> > the project
On Thu, Feb 15, 2024 at 12:15:52PM +0100, Enrico Weigelt, metux IT consult
wrote:
> Hello friends,
>
>
> is it intended that the check-merge-request job is always failing on
> non MR branches ?
>
When requesting a merge, I had errors with the CI. But this had to do
with the git commit
On Thu, Feb 15, 2024 at 12:04:42PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 14.02.24 21:37, tlaro...@kergis.com wrote:
>[...]
> > I think that the correct way is to state 'X11' or 'MIT' or
> > whatever matches COPYING or COPYRIGHTS or whatever file explains the
> > license status and
Some meson.build, for example, have a SPDX-License-Identifier: tag,
where "MIT" is mentionned, applying (I think) to the file itself, and
the project has an entry with a pair (license: 'MIT') applying to the
data by itself.
But, for example, xcbproto has a license with a (classical, for me)
On Thu, Feb 08, 2024 at 01:25:24PM +0100, Enrico Weigelt, metux IT consult
wrote:
> > >
> > > On which platforms is that still the case ?
> >
> > Platforms which support users starting the Xserver directly
> > (startx/xinit/etc
> > instead of via systemd service or display manager) on devices
should be easy (scriptable) to take this to convert to BSD make(1).
This work is public:
https://github.com/tlaronde/BeSiDe
the X11 stuff is not the NetBSD infrastructure one but is added, piece
by piece, in the X11/ subdir reaching other git clones places in ../X11
(relative to BeSiDe) with
On Tue, Feb 06, 2024 at 07:56:16AM +1000, Peter Hutterer wrote:
> On Mon, Feb 05, 2024 at 09:52:50PM +0100, tlaro...@kergis.com wrote:
> > Alan Coopersmith has applied the merge request for libXau---thanks!
> >
> > I had written 2 issues, related, against libXau, that the patches
> > address, so
On Mon, Feb 05, 2024 at 01:36:56PM -0800, Alan Coopersmith wrote:
> On 2/5/24 12:45, tlaro...@kergis.com wrote:
> > I'm continuing my review and I'm now looking at libxcb and xcbproto.
> >
> > Is there a goal set to switch from auto* tools to meson/ninja for the
> > maximum of projects?
>
> Yes
Alan Coopersmith has applied the merge request for libXau---thanks!
I had written 2 issues, related, against libXau, that the patches
address, so I have closed the issues after the merge.
It seems to me that writing issues against a module; providing patches
via a merge request; then closing the
I'm continuing my review and I'm now looking at libxcb and xcbproto.
Is there a goal set to switch from auto* tools to meson/ninja for the
maximum of projects?
Since I have to untangle things for my own built framework, I may as
well provide meson files (that are undoubtely more readable than
On Fri, Feb 02, 2024 at 08:56:26AM -0800, Alan Coopersmith wrote:
> On 2/2/24 04:14, tlaro...@kergis.com wrote:
> > I have asked for a merge request for libXau.
> >
> > I will very probably make other suggestions for other Xorg packages as
> > I go on with the work I'm doing around NetBSD.
> >
>
Hello,
On Fri, Feb 02, 2024 at 04:45:12PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 01.02.24 17:10, tlaro...@kergis.com wrote:
>
>
>
> since you're already working on libXau:
>
> do you happen to know any way for adding more data to auth tokens
> (w/o breaking file format) ?
>
>
I have asked for a merge request for libXau.
I will very probably make other suggestions for other Xorg packages as
I go on with the work I'm doing around NetBSD.
Are the merge requests triggering some note for developers (so the
merge request is sufficient per se), or do we need to drop on note
On Thu, Feb 01, 2024 at 09:31:13AM -0800, Alan Coopersmith wrote:
>
> Merge requests are preferred as they make it clear that a patch is ready
> to go in. Patches attached to issues are too easy to overlook.
FWIW, I have created a fork, committed 4 changes and request a merge
and the CI has
Hello,
On Thu, Feb 01, 2024 at 09:07:38AM -0800, Alan Coopersmith wrote:
> On 2/1/24 08:10, tlaro...@kergis.com wrote:
> > On Thu, Feb 01, 2024 at 04:54:57PM +0100, Olivier Fourdan wrote:
> > > On Thu, Feb 1, 2024 at 4:09?PM Enrico Weigelt, metux IT consult <
> > > i...@metux.net> wrote:
> > >
>
On Thu, Feb 01, 2024 at 04:54:57PM +0100, Olivier Fourdan wrote:
> On Thu, Feb 1, 2024 at 4:09?PM Enrico Weigelt, metux IT consult <
> i...@metux.net> wrote:
>
> > have you checked whether it's already on gitlab.freedesktop.org ?
> > In that case just make a PR there ?
> >
>
> Indeed, it's
Hello,
libXau has status "Unmaintained"
I'd like to apply two patches:
1) Test for __GNUC__ as well as __clang__ since gcc has no attributes
for __attribute((malloc)) as well;
2) Add a feature test to explicit_memset(3) supplementary to
explicit_bzero(3), since bzero(3) is deprecated (even
36 matches
Mail list logo
