similar to: [PATCH] run.in: Quote contents of @VAR@ substitutions

Add a bash function 'prepend' for intelligently prepending elements to paths. eg: prepend PYTHONPATH "/foo" would set PYTHONPATH to "/foo" or "/foo:<previous-contents-of-PYTHONPATH>" Tested by: (1) Building and testing libguestfs twice: first without libguestfs installed as a system library, and then with it installed. (2) Examining the output of

--- run.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/run.in b/run.in index 0d10983..0f23a7c 100755 --- a/run.in +++ b/run.in @@ -62,7 +62,7 @@ export PERL_VALGRIND=1 export PERL_DESTRUCT_LEVEL=2 # For Python. -export PYTHON=@PYTHON@ +export PYTHON="@PYTHON@" if [ -z "$PYTHONPATH" ]; then

On Friday 13 February 2015 10:16:34 Richard W.M. Jones wrote: > Add a bash function 'prepend' for intelligently prepending elements to > paths. eg: > > prepend PYTHONPATH "/foo" > > would set PYTHONPATH to "/foo" or "/foo:<previous-contents-of-PYTHONPATH>" > > Tested by: > > (1) Building and testing libguestfs twice:

This commit starts to split our massive, monolithic configure.ac file into smaller files, using the m4_include mechanism to combine them. I don't know if we should really do this, so I'm open to comments about it. However: - Our configure.ac script is 1800+ lines long, and that's pretty long. - configure.ac lacks structure; splitting it up might improve that. - From what I read,

Add makefile variables to enable silent rules for simple command invocations, such as ocamlc, ocamlopt, javac, and erlc. This reduces the log output when building with silent rules, still showing the full command lines otherwise. --- erlang/Makefile.am | 2 +- java/Makefile.am | 6 +++--- ocaml/Makefile.am | 14 +++++++------- subdir-rules.mk | 20 +++++++++++++++++--- 4 files changed,

CentOS Errata and Bugfix Advisory 2019:1331 Upstream details at : https://access.redhat.com/errata/RHBA-2019:1331 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 9c6dd8d64185f906a2c986de24737665f4ccc8bb416be4a96836427ca284185c gjs-1.52.5-1.el7_6.i686.rpm b121680a0fc63c5acdfebe41d16c71dd9dfc26e5bf4f290af87a7ac6ed596115

This simply compiles, passes tests, but is only able open a handle. This commit does not contain the full bindings. --- Makefile.am | 2 + configure.ac | 32 +++++ generator/GoLang.ml | 116 ++++++++++++++++++ generator/GoLang.mli | 19 +++ generator/Makefile.am

This simply compiles, passes tests, but is only able open a handle. This commit does not contain the full bindings. --- Makefile.am | 2 + configure.ac | 32 ++++ generator/GoLang.ml | 150 ++++++++++++++++++ generator/GoLang.mli | 19 +++ generator/Makefile.am

From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> --- generator/rust.ml | 13 ++++++++--- run.in | 9 ++++++++ rust/Cargo.lock | 6 +++++ rust/Cargo.toml | 4 +--- rust/tests/010_load.rs | 24 +++++++++++++++++++ rust/tests/020_create.rs | 24 +++++++++++++++++++

Update the check for the first line (the one containing the version) to match also the message with OpenJDK; switch to awk so it is easier to extract the version inside the double quotes. --- m4/guestfs_java.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/m4/guestfs_java.m4 b/m4/guestfs_java.m4 index f9bec94..649e21f 100644 --- a/m4/guestfs_java.m4 +++ b/m4/guestfs_java.m4

> I guess this is a stray debug message? Yes. I'm sorry... > we did *not* check them into git. Really? Does it mean that every time you build the library, Cargo.toml is generated? > The actual test parts of this patch are fine, but you need to spend a > bit of time with ‘git rebase -i’ to move parts of patch 3 into patch 2. Does this mean that the followings should be moved to

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

On Thu, Jun 27, 2019 at 05:06:04PM +0900, Hiroyuki Katsura wrote: > From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> > > --- > generator/rust.ml | 13 ++++++++--- > run.in | 9 ++++++++ > rust/Cargo.lock | 6 +++++ > rust/Cargo.toml | 4 +--- > rust/tests/010_load.rs

On Thu, Jun 27, 2019 at 06:27:05PM +0900, Hiroyuki Katsura wrote: > > I guess this is a stray debug message? > > Yes. I'm sorry... > > > we did *not* check them into git. > > Really? Does it mean that every time you build the library, Cargo.toml is > generated? That's how it has worked in nbdkit. Whether it's right or not I don't know. Normally

Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> --- align/test-virt-alignment-scan-guests.sh | 2 +- align/test-virt-alignment-scan.sh | 2 +- builder/test-virt-builder-planner.sh | 2 +- builder/website/ubuntu.sh | 2 +- configure.ac | 2 +- fish/test-mount-local.sh | 2 +- make-fs/test-virt-make-fs.sh | 2 +-

Since we removed gtk doc, we might as well replace it with a manual page explaining the basics of how to run gjs. --- .gitignore | 2 ++ docs/guestfs-recipes.pod | 1 + erlang/examples/guestfs-erlang.pod | 1 + gobject/Makefile.am | 19 +++++++++++ gobject/guestfs-gobject.pod | 64 ++++++++++++++++++++++++++++++++++++++

I tried using Javascript (gjs) with GObject-Introspection and did a port of the create_disk example which is attached below. Quite a bit of time was spent looking up stuff in the GLib reference and guessing how certain idioms translate to gjs. I used the traditional add_drive_opts method since I haven't been able to find how to specify the optional arguments to add_drive_opts. How does that

This is the first iteration of the GObject bindings. I have 'kicked the tyres' on these, meaning I have ensured that a bunch of basic manual tests work as expected. I'm in the process of adding more comprehensive tests. Here's an example simple javascript program which uses these bindings: === const Guestfs = imports.gi.Guestfs; print('Starting'); var g = new

I noticed some uses of ${srcdir} in shell scripts. That is almost always better written as $srcdir. The patch below converts most such variable references. Here are the few remaining candidates: $ git grep -i -E '\$\{[a-zA-Z_0-9]+\}'|grep -v Makefile.in.in configure.ac: JAR_INSTALL_DIR=\${prefix}/share/java configure.ac: JNI_INSTALL_DIR=\${libdir} debian/rules: for TEST in

Output each path where we attempt to find 'java', so it is easier to spot whether the location for the current OS is missing. This also removes the need to print the location next to the version, since the location was already printed above. --- m4/guestfs_java.m4 | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/m4/guestfs_java.m4 b/m4/guestfs_java.m4 index