On 14-04-30 05:40 AM, Quentin Glidic wrote:
On 2014-04-27 22:41, Matthew Brush wrote:
On 14-04-27 01:08 PM, Colomban Wendling wrote:
Le 27/04/2014 21:24, Matthew Brush a écrit :
Yeah I guess AM_PROG_VALAC() just issues those warnings instead
of failing as I'd have expected.
In a perfect world, the generated *.[ch] files would be
distributed and when compiling (from tarball at least) no Vala
compiler would be required.
GNOME folks just say that distributing generated files was a bad design
idea.
I can understand this, however not requiring an extra build-time
dependency where not strictly necessary might improve chances of getting
distributed (especially ex. on windows, not that multiterm counts :)
That's the very reason why the absence of valac doesn't trigger a
failure (hence disabling the plugin): because tarballs include the
C sources, and then valac isn't required unless you want to change
the Vala source.
I'm not sure what we can do here… maybe magically detect it's not
a tarball and then require valac? Not sure.
One not great option would be to check-in the generated source.
Just require this little dependency that Vala is for everyone.
I'm not strictly opposed, but if it saves someone that is using the
tarball/dist from having to install a bunch of Vala stuff even if they
have no intention of modifying the original Vala sources, and Valac
conveniently outputs nice portable C code, then I'm not sure.
Or consider that Git = non-tarball and do:
if test -d .git -a -z "$VALAC"; then
AC_MSG_ERROR([valac is required to build from Git])
fi
I like this concept best... if you forced on Multiterm/etc/Vala, and
you're building from Git, then you need Valac, else soft-fail and just
use generated C sources from dist, unless explicitly disabled.
Cheers,
Matthew Brush
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
