I've recently started using automake with Vala; it works very well! I'm
particularly impressed that the "make dist" rules include the C files, so
that the builder doesn't need a Vala compiler.
There's one nit: I want to make multiple .c files from the same .vala file,
analogous to the way that
I attach a patch relative to current git that improves contrib/README.
--
https://rrt.sc3d.org
From 759746989cc75c2a929c09b28226d9be18d64a21 Mon Sep 17 00:00:00 2001
From: Reuben Thomas
Date: Thu, 15 Oct 2020 13:11:11 +0100
Subject: [PATCH] contrib/README: fix and clarify the English
---
On Thu, 15 Oct 2020 at 13:06, Reuben Thomas wrote:
> I've recently started using automake with Vala; it works very well! I'm
> particularly impressed that the "make dist" rules include the C files, so
> that the builder doesn't need a Vala compiler.
>
> There's one nit: I want to make multiple
I'm sorry, I see this question is covered in the manual:
Note that currently, you cannot use per-target ‘*_VALAFLAGS’ (*note
> Renamed Objects::) to produce different C files from one Vala source
> file.
>
Feel free to close this issue!
On Thu, 15 Oct 2020 at 22:09, Karl Berry wrote:
>
> I found some long-ago patches (not for this particular issue) from a
> previous contributor (Daniel Espinosa), which surely worked at the time
> they were written, but now break things. And Daniel stopped replying to
> my mail. Sorry to be so
Attached, a patch to improve valac version detection. The vala compiler,
valac, can report the API version it supports. For releases, this is the
same as the major & minor version of the compiler, so for example:
$ valac --version
Vala 0.48.11
$ valac --api-version
0.48
The advantage of using
Sorry, I simply failed to update the test; I noticed a failure message, and
didn't understand it. Simply lack of effort on my part, apologies.
I attach an updated patch, which now also patches the test to account for
the new mode of operation (checking --api-version not --version) and
updated
I've had a look at the patch now, and found and fixed one bug.
However, an issue comes up for VPATH builds that needs a more thorough fix:
C files generated from Vala sources are shipped by "make dist" and hence
end up in srcdir, but in a VPATH build with a Vala compiler, they will be
in
[CCing the bug, though this email wasn't addressed to it; looks like it
should have been, though!]
Indeed, the generated C file shouldn't be rebuilt; the existing distributed
C source file should be used.
I tried the test with v1.16.3 and it passed for me. Looking at the logs, I
found this line
On Thu, 3 Dec 2020 at 22:17, Karl Berry wrote:
> Hi Reuben,
>
> There doesn't seem to be a way for the user to configure a different
> ctags program
>
> I don't know of anything to the contrary. So ... would you be up for
> making a patch to support it :)? Etags too, I guess? At least
On Thu, 3 Dec 2020 at 22:26, Reuben Thomas wrote:
>
> Happy to look into it.
>
I have looked into it and attach a trivial patch, which works nicely.
It's not obvious to me whether any documentation is required; I rather
expected that these variables would behave like others (CC, CXX etc.).
I just noticed while updating to look at something else that a version of
my patch seems to have been applied, but with a misleading commit message.
It has my name on it, commit 7581ec208. But I don't think I had anything to
do with that commit!
The commit log says: "reverse -newer test". But it
On Fri, 4 Dec 2020 at 22:20, Karl Berry wrote:
> You sent the proposed change in the bug report to Bruno, so I committed
> it in your name.
>
Sorry, I didn't mean to say I had nothing to do with the contents of the
patch, just that I didn't have anything to do with installing it. (And I
wasn't
The example filename "zardoc.c" in the Vala section should be "zardoz.c";
it doesn't really matter, but it is almost certainly a typo.
--
https://rrt.sc3d.org
There doesn't seem to be a way for the user to configure a different ctags
program, unless I'm overlooking something? Passing "CTAGS=foo" to configure
has no effect; it seems that all one can do is pass "CTAGS=foo" to make
every time one runs "make tags".
--
https://rrt.sc3d.org
On Sat, 21 Nov 2020 at 22:01, Karl Berry wrote:
>
> By the way, I don't think that find command (or the cp -p for that
> matter) is excessively portable. But I guess we don't much care about
> crufty systems for vala support. --thanks, karl.
>
They are both using only POSIX-2008 features; these
To follow up clearly: if it were up to me, I'd install an acceptable
version of my patch, as it improves the status quo, and include it in the
next release. Then I'd think about whether it's possible to redo the Vala
support entirely.
--
https://rrt.sc3d.org
On Wed, 28 Oct 2020 at 20:37, Karl Berry wrote:
>
> As I wrote before, I strongly support this approach. Since the C file is
> derived, don't distribute it. Would that simplify the patch?
>
A patch to re-do Vala support would be a larger patch at this stage, though
overall it would certainly
On Fri, 30 Oct 2020 at 01:45, Karl Berry wrote:
> install an acceptable version of my patch, as it improves the status
> quo, and include it in the next release. Then I'd think about
> whether it's possible to redo the Vala support entirely.
>
> Sounds sensible.
>
> I applied your
Or, bug #11347 again.
I just spent quite a while chasing down a test failure that was due to
testsuite-part.am not being remade when new tests were added.
I duly found bug #11347, which contains a rationale for not having
testsuite-part.am depend on all the tests.
However, the rationale doesn't
I have taken Daniel Espinosa's patch and improved it so that it fixes all
the test failures. Some of the failures were actually left-over changes to
the tests required by Daniel's patch, which (correctly) considers the
primary location of C files generated by valac to be builddir, not srcdir.
One
On Sat, 7 Jan 2023 at 08:46, Nick Bowler wrote:
>
> This example in the manual is talking about writing a custom
> Makefile, *without* using Automake, that you want to recurse
> into using Automake's SUBDIRS feature.
>
Aha! Thanks for pointing this out. I think the manual is misleading in
On Sun, 8 Jan 2023 at 00:23, Karl Berry wrote:
> How does this change to the doc look? --thanks, karl.
>
Thanks for this Karl; it certainly fixes the problem I had! (I'll leave the
assessment of technical accuracy to others.)
--
https://rrt.sc3d.org
I found the "Rules-*" feature of gettext to do this; sorry for the noise!
--
https://rrt.sc3d.org
I have an automake project with a 'po' subdirectory whose contents,
including Makefile.in.in, is entirely generated by gettext. 'po' is in my
top level Makefile.am's SUBDIRS.
When I add an AM_EXTRA_RECURSIVE_TARGETS entry, say 'foo', automake tries
to recurse into po and 'make foo', and of course
I'm using automake 1.16.5. The advice about how to disable the "dvi" target
doesn't seem to work.
In the manual it says:
To make ‘dvi’ into a do-nothing target, see the example for
‘EMPTY_AUTOMAKE_TARGETS’ in *note Third-Party Makefiles::.
If I have:
EMPTY_AUTOMAKE_TARGETS = dvi
.PHONY:
On Wed, 12 Apr 2023 at 16:17, Reuben Thomas wrote:
> I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do
> a parallel build (in my case, MAKEFLAGS=-j4), I get build failures
> sometimes:
>
In fact, I don't need to do a parallel build, just build serially from a
fresh git
I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do a
parallel build (in my case, MAKEFLAGS=-j4), I get build failures sometimes:
$ make all
make all-am
make[1]: Entering directory '/home/rrt/.local/var/repo/a2ps/src'
YACC parsessh.c
CC libparse_a-lexssh.o
On Wed, 12 Apr 2023 at 17:59, Reuben Thomas wrote:
> On Wed, 12 Apr 2023 at 16:17, Reuben Thomas wrote:
>
>> I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do
>> a parallel build (in my case, MAKEFLAGS=-j4), I get build failures
>> sometimes:
>>
>
> In fact, I don't need
Using automake 1.16.5, in my Makefile.am, I have the following lines:
noinst_LTLIBRARIES = liba2ps.la
liba2ps_la_LDFLAGS = $(LIBGC_LIBS)
liba2ps_la_SOURCES = $(liba2pssources) $(libitsources) $(mylibitsources)
liba2ps_la_LIBADD = ../lib/libgnu.la $(LIBINTL) $(LIBSOCKET)
$(GETHOSTNAME_LIB)
On Sun, 5 Feb 2023 at 06:09, Nick Bowler wrote:
>
> What Automake is trying to tell you is that LDFLAGS is meaningless
> on a static library. This message could definitely be improved!
>
Of course, thanks! I was confused because in another Makefile.am that had
only a static library I did not
On Sun, 3 Dec 2023 at 03:47, Mike Frysinger wrote:
> >
> > I think I've worked it out: I need to add the .c file that is generated
> > from the .y file, not the .h file, to BUILT_SOURCES. Certainly, doing
> that
> > fixes the problem.
>
> we prob could add a .y/.l example to the manual. i think
On Sat, 9 Dec 2023 at 00:03, Karl Berry wrote:
> The manual currently says: "You should never explicitly mention the
> intermediate (C or C++) file in any `SOURCES' variable; only list
> the source file."
>
> I don't know the code here, and this probably wasn't the question, but I
>
On Sat, 9 Dec 2023 at 15:16, Reuben Thomas wrote:
>
> If you're happy with that, I'll write a patch.
>
Patch attached.
--
https://rrt.sc3d.org
From 06f6765b7d10132d0dcefde1265b4d5f01df76b4 Mon Sep 17 00:00:00 2001
From: Reuben Thomas
Date: Sat, 9 Dec 2023 15:20:44 +0200
Subject: [PATCH] doc:
On Wed, 6 Dec 2023 at 23:59, Karl Berry wrote:
> Any chance that one of you could write a patch for the manual to explain
> whatever needs to be explained (better)? --thanks, karl.
>
I'd happily do that if I could work out, or someone could explain, exactly
what's going on here.
The manual
On Sat, 27 Apr 2024 at 00:53, Karl Berry wrote:
> Reuben, any chance you can whomp up a test for this patch?
>
No problem, I will do this when I can find a moment. Since I don't actually
need this fix after all, it may not be quick!
--
https://rrt.sc3d.org
I attach two patches. The first is a trivial documentation fix. The second
fixes a bug I ran into recently with Vala compilation.
I just needed to add some Vala source files to my program that are added to
the relevant _SOURCES variable conditionally:
if OS_WIN32
libenchant_la_SOURCES +=
On Wed, 24 Apr 2024 at 23:38, Reuben Thomas wrote:
> Apologies, I should have run the tests before posting the patch. Indeed, I
> have broken things. So, please consider the documentation patch, and I'll
> take another look at the bug-fix (which in any case I have also realised
> does not solve
On Wed, 24 Apr 2024 at 22:57, Reuben Thomas wrote:
>
> The patch is trivial, so hopefully it's obvious if there's a problem for
> some reason! I hope I explained well enough what problem I'm trying to
> solve.
>
Apologies, I should have run the tests before posting the patch. Indeed, I
have
On Mon, 29 Apr 2024 at 23:29, Karl Berry wrote:
>
> All I know about Vala is what you've written, but given that, I do agree
> it would be useful to document it. So a doc patch would be most welcome.
>
Attached.
--
https://rrt.sc3d.org
From eead600ffcf3d2ad56f2da25ea8371dca40432ea Mon Sep 17
On Sat, 27 Apr 2024 at 20:36, Reuben Thomas wrote:
> On Sat, 27 Apr 2024 at 00:53, Karl Berry wrote:
>
>> Reuben, any chance you can whomp up a test for this patch?
>>
>
> No problem, I will do this when I can find a moment. Since I don't
> actually need this fix after all, it may not be quick!
41 matches
Mail list logo
