| Message ID | CAPAYC_y98TxMoBtG=P9hDe26=1rHfaoMyoH5NJyLHbRxcxpMAQ@mail.gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
| Series | "PATCH": hack to be able to build Rust targetting MIPS | expand |
After patching, after some long compilation I get:
8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8<
Building stage0 tool fabricate (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.40s
Install docs stage2 (Some("x86_64-unknown-linux-gnu"))
touch: cannot touch '/usr/local/lib/rust-install-probe': Permission denied
install: error: can't write to destination. consider `sudo`.
command did not execute successfully: "sh"
"/home/alex/git/buildroot/output/build/host-rust-1.33.0/build/tmp/dist/rust-docs-1.33.0-dev-x86_64-unknown-linux-gnu/install.sh"
"--prefix=/usr/local" "--sysconfdir=/etc" "--datadir=/usr/local/share"
"--docdir=/usr/local/share/doc/rust" "--bindir=/usr/local/bin"
"--libdir=/usr/local/lib" "--mandir=/usr/local/share/man"
"--disable-ldconfig"
expected success, got: exit code: 1
failed to run:
/home/alex/git/buildroot/output/build/host-rust-1.33.0/build/bootstrap/debug/bootstrap
install
Build completed unsuccessfully in 0:01:12
make: *** [package/pkg-generic.mk:271:
/home/alex/git/buildroot/output/build/host-rust-1.33.0/.stamp_host_installed]
Error 1
8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8<
I'd rather not sudo, as it seems that would bork my rustup-installed Rust?
Cheers,
Álex
On Sat, Jan 18, 2020 at 7:46 PM Alex Corcoles <alex@corcoles.net> wrote:
> Hi guys,
>
> I'm trying to build mipsel Rust stuff, and I've had to do this:
>
> 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8<
> From 8c3f68a687b4f94a7c2e20e2020fd1e6f9e2c414 Mon Sep 17 00:00:00 2001
> From: alex <alex@pdp7.net>
> Date: Sat, 18 Jan 2020 19:24:57 +0100
> Subject: [PATCH 1/1] Set RUSTC_TARGET_NAME
>
> Signed-off-by: alex <alex@pdp7.net>
> ---
> package/rust/rust.mk | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/package/rust/rust.mk b/package/rust/rust.mk
> index 5d14fc6682..258daef331 100644
> --- a/package/rust/rust.mk
> +++ b/package/rust/rust.mk
> @@ -38,6 +38,8 @@ endef
>
> HOST_RUST_POST_EXTRACT_HOOKS += HOST_RUST_EXCLUDE_ORIG_FILES
>
> +RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-gnu$(RUSTC_ABI)
> +
> define HOST_RUST_CONFIGURE_CMDS
> ( \
> echo '[build]'; \
> --
> 2.20.1
>
> 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8<
>
> To advance things up (I'm currently compiling LLVM, apparently), as
> otherwise the config.toml created is wrong. I'm attaching the .config I'm
> using (I'm using the non-pre-built host rust- the pre-built one apparently
> doesn't have std).
>
> I certainly doubt what I'm doing is "correct", but maybe you guys want to
> take a look at it.
>
> BTW, tried to cc: Eric as instructed by get-developers, but mail to him
> bounced...
>
> Cheers,
>
> Álex
> --
> ___
> {~._.~}
> ( Y )
> ()~*~() mail: alex at corcoles dot net
> (_)-(_) http://alex.corcoles.net/
>
>
>
> --
> ___
> {~._.~}
> ( Y )
> ()~*~() mail: alex at corcoles dot net
> (_)-(_) http://alex.corcoles.net/
>
>
Alex, All, On 2020-01-18 19:46 +0100, Alex Corcoles spake thusly: > Hi guys, > I'm trying to build mipsel Rust stuff, and I've had to do this: > 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< > From 8c3f68a687b4f94a7c2e20e2020fd1e6f9e2c414 Mon Sep 17 00:00:00 2001 > From: alex < [1]alex@pdp7.net> > Date: Sat, 18 Jan 2020 19:24:57 +0100 > Subject: [PATCH 1/1] Set RUSTC_TARGET_NAME > > Signed-off-by: alex < [2]alex@pdp7.net> > --- > package/rust/ [3]rust.mk | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/package/rust/ [4]rust.mk b/package/rust/ [5]rust.mk > index 5d14fc6682..258daef331 100644 > --- a/package/rust/ [6]rust.mk > +++ b/package/rust/ [7]rust.mk > @@ -38,6 +38,8 @@ endef > > HOST_RUST_POST_EXTRACT_HOOKS += HOST_RUST_EXCLUDE_ORIG_FILES > > +RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-gnu$(RUSTC_ABI) RUSTC_TARGET_NAME is defined in package/rustc/rustc.mk: 10 ifeq ($(BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS),y) 11 RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-gnu$(RUSTC_ABI) 12 endif So, it is only defined if BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is set, and this is defined in package/rustc/Config.in.host. It needs a glibc toolchain (and an x86 or x86_64 host machine). But your configuration uses uClibc-ng, not glibc, so this is the reason that it does not work for you. If you believe the dependency on glibc is too stringent, then this is the place to fix stuff, not redefine the variable as you suggested. Regards, Yann E. MORIN. > define HOST_RUST_CONFIGURE_CMDS > ( \ > echo '[build]'; \ > -- > 2.20.1 > 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< 8< > To advance things up (I'm currently compiling LLVM, apparently), as otherwise the config.toml created is wrong. I'm attaching the > .config I'm using (I'm using the non-pre-built host rust- the pre-built one apparently doesn't have std). > I certainly doubt what I'm doing is "correct", but maybe you guys want to take a look at it. > BTW, tried to cc: Eric as instructed by get-developers, but mail to him bounced... > Cheers, > Álex > -- > ___ > {~._.~} > ( Y ) > ()~*~() mail: alex at corcoles dot net > (_)-(_) [8]http://alex.corcoles.net/ > > -- > ___ > {~._.~} > ( Y ) > ()~*~() mail: alex at corcoles dot net > (_)-(_) [9]http://alex.corcoles.net/ > > Links: > 1. mailto:alex@pdp7.net > 2. mailto:alex@pdp7.net > 3. http://rust.mk > 4. http://rust.mk > 5. http://rust.mk > 6. http://rust.mk > 7. http://rust.mk > 8. http://alex.corcoles.net/ > 9. http://alex.corcoles.net/ > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
> RUSTC_TARGET_NAME is defined in package/rustc/rustc.mk: > > 10 ifeq ($(BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS),y) > 11 RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-gnu$(RUSTC_ABI) > 12 endif > > So, it is only defined if BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is > set, and this is defined in package/rustc/Config.in.host. It needs a > glibc toolchain (and an x86 or x86_64 host machine). > > But your configuration uses uClibc-ng, not glibc, so this is the reason > that it does not work for you. > > If you believe the dependency on glibc is too stringent, then this is > the place to fix stuff, not redefine the variable as you suggested. > Honestly, I don't have any idea what I'm doing :) Rust itself supports uclibc on mipsel: https://forge.rust-lang.org/release/platform-support.html mipsel-unknown-linux-uclibc is a Tier 3 platform, which is not awesome, but it could work. Frankly I don't know much about buildroot to hack this up (or even to know if it's worth trying). (I'm just trying to run rust-sdl/rust-sdl2 on a RG-300 which uses buildroot for development purposes. I've managed to build C stuff using SDL successfully in buildroot, but Rust is proving to be more complex)
Hi! On 2020-01-18 19:46, Alex Corcoles wrote: > Hi guys, > > I'm trying to build mipsel Rust stuff, and I've had to do this: [...] > > HOST_RUST_POST_EXTRACT_HOOKS += HOST_RUST_EXCLUDE_ORIG_FILES > > +RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-gnu$(RUSTC_ABI) > + [...] > To advance things up (I'm currently compiling LLVM, apparently), as > otherwise the config.toml created is wrong. I'm attaching the .config I'm > using (I'm using the non-pre-built host rust- the pre-built one apparently > doesn't have std). > > I certainly doubt what I'm doing is "correct", but maybe you guys want to > take a look at it. The RUSTC_TARGET_NAME variable is defined in rustc.mk only if the symbol BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is selected. This symbols is used to ensure all the conditions to build a rust package are met. One of them is that the toolchain is glibc-based. This is required, because the standard library provided by the pre-built host Rust toolchain is built against glibc. In your defconfig, the toolchain is uclibc-based and the host Rust toolchain is built from source. Hence BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is not defined and so is RUSTC_TARGET_NAME. So there is a bug: the restriction on having a glibc-based toolchain should apply either when using a pre-built rust toolchain or building one from source. I'll see how to fix it. The list of supported platforms [1] mentions GNU glibc and musl, but not uclibc. Does the build with your defconfig and patch successful? [1] https://forge.rust-lang.org/release/platform-support.html Regards, -- ELB
Hi! The RUSTC_TARGET_NAME variable is defined in rustc.mk only if the symbol > BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is selected. This symbols is > used to ensure all the conditions to build a rust package are met. One > of them is that the toolchain is glibc-based. This is required, because > the standard library provided by the pre-built host Rust toolchain is > built against glibc. > > In your defconfig, the toolchain is uclibc-based and the host Rust > toolchain is built from source. > > Hence BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is not defined and so > is RUSTC_TARGET_NAME. > > So there is a bug: the restriction on having a glibc-based toolchain > should apply either when using a pre-built rust toolchain or building > one from source. I'll see how to fix it. > > The list of supported platforms [1] mentions GNU glibc and musl, but not > uclibc. Does the build with your defconfig and patch successful? > > [1] https://forge.rust-lang.org/release/platform-support.html > I think I built it successfully after introducing my hack, but as far as I understand, it is not guaranteed to build in the future (and the opposite is true, perhaps if it doesn't build today, it will tomorrow). In the link you sent, mipsel-unknown-linux-uclibc is Tier 3 with std. If I have some time I will play around with it and see you some results. IMHO, perhaps you should hide non Tier-1 platforms behind an "enable this option for non-Tier 1 Rust builds which are not guaranteed to work", or something like that. Cheers, Álex
I've finally had more time to play with this. It seems that mipsel-unknown-linux-uclibc works! I've been able to run software built with it on a real hardware device, although it's very crashy (all arithmetic operations seem to crash with illegal instruction- probably I didn't configure my toolchain right or there's a Rust issue...). I would suggest removing the limitation on uclibc... perhaps with a big warning flag, though, as I haven't managed to build complex, stable software. I've written a bit about the process at: https://users.rust-lang.org/t/trying-to-compile-rust-sdl-stuff-for-a-rg300-console-buildroot-mipsel-uclibc/36722 https://github.com/alexpdp7/retrofw2-rust Cheers, Álex On Mon, Jan 20, 2020 at 5:31 PM Alex Corcoles <alex@corcoles.net> wrote: > Hi! > > The RUSTC_TARGET_NAME variable is defined in rustc.mk only if the symbol >> BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is selected. This symbols is >> used to ensure all the conditions to build a rust package are met. One >> of them is that the toolchain is glibc-based. This is required, because >> the standard library provided by the pre-built host Rust toolchain is >> built against glibc. >> >> In your defconfig, the toolchain is uclibc-based and the host Rust >> toolchain is built from source. >> >> Hence BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is not defined and so >> is RUSTC_TARGET_NAME. >> >> So there is a bug: the restriction on having a glibc-based toolchain >> should apply either when using a pre-built rust toolchain or building >> one from source. I'll see how to fix it. >> >> The list of supported platforms [1] mentions GNU glibc and musl, but not >> uclibc. Does the build with your defconfig and patch successful? >> >> [1] https://forge.rust-lang.org/release/platform-support.html >> > > I think I built it successfully after introducing my hack, but as far as I > understand, it is not guaranteed to build in the future (and the opposite > is true, perhaps if it doesn't build today, it will tomorrow). In the link > you sent, mipsel-unknown-linux-uclibc is Tier 3 with std. > > If I have some time I will play around with it and see you some results. > > IMHO, perhaps you should hide non Tier-1 platforms behind an "enable this > option for non-Tier 1 Rust builds which are not guaranteed to work", or > something like that. > > Cheers, > > Álex > > -- > ___ > {~._.~} > ( Y ) > ()~*~() mail: alex at corcoles dot net > (_)-(_) http://alex.corcoles.net/ > >
I've finally had more time to play with this. It seems that mipsel-unknown-linux-uclibc works! I've been able to run software built with it on a real hardware device, although it's very crashy (all arithmetic operations seem to crash with illegal instruction- probably I didn't configure my toolchain right or there's a Rust issue...). I would suggest removing the limitation on uclibc... perhaps with a big warning flag, though, as I haven't managed to build complex, stable software. I've written a bit about the process at: https://users.rust-lang.org/t/trying-to-compile-rust-sdl-stuff-for-a-rg300-console-buildroot-mipsel-uclibc/36722 https://github.com/alexpdp7/retrofw2-rust Cheers, Álex On Mon, Jan 20, 2020 at 5:31 PM Alex Corcoles <alex@corcoles.net> wrote: > Hi! > > The RUSTC_TARGET_NAME variable is defined in rustc.mk only if the symbol >> BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is selected. This symbols is >> used to ensure all the conditions to build a rust package are met. One >> of them is that the toolchain is glibc-based. This is required, because >> the standard library provided by the pre-built host Rust toolchain is >> built against glibc. >> >> In your defconfig, the toolchain is uclibc-based and the host Rust >> toolchain is built from source. >> >> Hence BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is not defined and so >> is RUSTC_TARGET_NAME. >> >> So there is a bug: the restriction on having a glibc-based toolchain >> should apply either when using a pre-built rust toolchain or building >> one from source. I'll see how to fix it. >> >> The list of supported platforms [1] mentions GNU glibc and musl, but not >> uclibc. Does the build with your defconfig and patch successful? >> >> [1] https://forge.rust-lang.org/release/platform-support.html >> > > I think I built it successfully after introducing my hack, but as far as I > understand, it is not guaranteed to build in the future (and the opposite > is true, perhaps if it doesn't build today, it will tomorrow). In the link > you sent, mipsel-unknown-linux-uclibc is Tier 3 with std. > > If I have some time I will play around with it and see you some results. > > IMHO, perhaps you should hide non Tier-1 platforms behind an "enable this > option for non-Tier 1 Rust builds which are not guaranteed to work", or > something like that. > > Cheers, > > Álex > > -- > ___ > {~._.~} > ( Y ) > ()~*~() mail: alex at corcoles dot net > (_)-(_) http://alex.corcoles.net/ > >
Some further investigation reveals that Rust made the mips* targets mips32r2 by default, while the system I'm trying to compile to is only mips32 (no r2). This seems to be the source of my issues: https://github.com/rust-lang/rust/pull/48874 So if buildroot wants Rust to work on JZ4760B and similar popular CPUs, I think it should define a new Rust target for mips32 without r2 instruction set. That goes a bit beyond my knowledge (esp. buildroot), so if someone wants to help, I'd be happy to do whatever I can. On Mon, Feb 3, 2020 at 6:08 PM Alex Corcoles <alex@corcoles.net> wrote: > I've finally had more time to play with this. It seems that > mipsel-unknown-linux-uclibc works! I've been able to run software built > with it on a real hardware device, although it's very crashy (all > arithmetic operations seem to crash with illegal instruction- probably I > didn't configure my toolchain right or there's a Rust issue...). > > I would suggest removing the limitation on uclibc... perhaps with a big > warning flag, though, as I haven't managed to build complex, stable > software. > > I've written a bit about the process at: > > > https://users.rust-lang.org/t/trying-to-compile-rust-sdl-stuff-for-a-rg300-console-buildroot-mipsel-uclibc/36722 > https://github.com/alexpdp7/retrofw2-rust > > Cheers, > > Álex > > On Mon, Jan 20, 2020 at 5:31 PM Alex Corcoles <alex@corcoles.net> wrote: > >> Hi! >> >> The RUSTC_TARGET_NAME variable is defined in rustc.mk only if the symbol >>> BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is selected. This symbols is >>> used to ensure all the conditions to build a rust package are met. One >>> of them is that the toolchain is glibc-based. This is required, because >>> the standard library provided by the pre-built host Rust toolchain is >>> built against glibc. >>> >>> In your defconfig, the toolchain is uclibc-based and the host Rust >>> toolchain is built from source. >>> >>> Hence BR2_PACKAGE_HOST_RUSTC_TARGET_ARCH_SUPPORTS is not defined and so >>> is RUSTC_TARGET_NAME. >>> >>> So there is a bug: the restriction on having a glibc-based toolchain >>> should apply either when using a pre-built rust toolchain or building >>> one from source. I'll see how to fix it. >>> >>> The list of supported platforms [1] mentions GNU glibc and musl, but not >>> uclibc. Does the build with your defconfig and patch successful? >>> >>> [1] https://forge.rust-lang.org/release/platform-support.html >>> >> >> I think I built it successfully after introducing my hack, but as far as >> I understand, it is not guaranteed to build in the future (and the opposite >> is true, perhaps if it doesn't build today, it will tomorrow). In the link >> you sent, mipsel-unknown-linux-uclibc is Tier 3 with std. >> >> If I have some time I will play around with it and see you some results. >> >> IMHO, perhaps you should hide non Tier-1 platforms behind an "enable this >> option for non-Tier 1 Rust builds which are not guaranteed to work", or >> something like that. >> >> Cheers, >> >> Álex >> >> -- >> ___ >> {~._.~} >> ( Y ) >> ()~*~() mail: alex at corcoles dot net >> (_)-(_) http://alex.corcoles.net/ >> >> > > -- > ___ > {~._.~} > ( Y ) > ()~*~() mail: alex at corcoles dot net > (_)-(_) http://alex.corcoles.net/ > >
Hi guys, Just managed to get everything working. I've documented the whole process at: https://github.com/alexpdp7/retrofw2-rust The problems are: 1) Rust updated their mips targets to mips32r2, while the kind of devices I'm using are plain non-r1 mips32. I created a patch for buildroot that patches Rust (on top of a patch I found that bumps it to Rust 1.40.0) to use the proper instruction set. I've opened a bug to see if they change the target or add a new one at: https://github.com/rust-lang/rust/issues/68865 2) buildroot doesn't support building Rust for uclibc, I hardcoded that. It would be nice to write a proper solution to this, but I'm not familiar enough with buildroot. Does anyone know where I could request that? 3) I had some issues with sdl-mixer, which I fixed by pulling RetroFW's sdl-mixer. This is even more terrible, but I have even less idea about how to fix it. Cheers, Álex
Alex, On 2/6/20 11:18 AM, Alex Corcoles wrote: > Hi guys, > > Just managed to get everything working. I've documented the whole > process at: > > https://github.com/alexpdp7/retrofw2-rust > > The problems are: > > 1) Rust updated their mips targets to mips32r2, while the kind of > devices I'm using are plain non-r1 mips32. I created a patch for > buildroot that patches Rust (on top of a patch I found that bumps it > to Rust 1.40.0) to use the proper instruction set. I've opened a bug > to see if they change the target or add a new one at: > > https://github.com/rust-lang/rust/issues/68865 > I'm not familiar with Rust, but there should be a cleaner way to set the target cpu than hacking the default. Preferably the target MIPS cpu selected within Buildroot would inform the target cpu? A quick search seems to suggest this may be possible (https://gitissue.com/issues/5a1e9e776805170abd3c8a38): [build] target = "mipsel-unknown-linux-gnu" [target.mipsel-unknown-linux-gnu] rustflags = [ "-C", "link-arg=-EL", "-C", "target-cpu=mips32", "-C", "target-feature=+mips32,-mips32r2,-fpxx,-nooddspreg", ] > 2) buildroot doesn't support building Rust for uclibc, I hardcoded > that. It would be nice to write a proper solution to this, but I'm not > familiar enough with buildroot. Does anyone know where I could request > that? > > 3) I had some issues with sdl-mixer, which I fixed by pulling > RetroFW's sdl-mixer. This is even more terrible, but I have even less > idea about how to fix it. > > Cheers, > > Álex > > -- > ___ > {~._.~} > ( Y ) > ()~*~() mail: alex at corcoles dot net > (_)-(_) http://alex.corcoles.net/ > > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Hi Vincent, On Thu, Feb 6, 2020 at 6:50 PM Vincent Fazio <vfazio@xes-inc.com> wrote: > I'm not familiar with Rust, but there should be a cleaner way to set the > target cpu than hacking the default. Preferably the target MIPS cpu > selected within Buildroot would inform the target cpu? > > A quick search seems to suggest this may be possible > (https://gitissue.com/issues/5a1e9e776805170abd3c8a38): > > [build] > target = "mipsel-unknown-linux-gnu" > > [target.mipsel-unknown-linux-gnu] > rustflags = [ > "-C", "link-arg=-EL", > "-C", "target-cpu=mips32", > "-C", "target-feature=+mips32,-mips32r2,-fpxx,-nooddspreg", > ] > Yeah, probably there are slightly cleaner solutions. I think that Rust targetting mips32r2 by default sucks a little bit, so I'm not losing hope completely that the change will be reverted. If they do so, I think it would be quite easy for buildroot to iron out the few niggles required to get this to work. However, I'm not really knowledgeable about buildroot, so all the patches involved in this are terrible. I saw the solution you quote at: https://github.com/rust-lang/rust/issues/37507#issuecomment-476026815 , but I wasn't sure how to plug that cleanly into buildroot, so I went for the ugly solution. Perhaps I can plug that into buildroot/package/rust/ rust.mk, though. If I have some time I will try to clean things up (unfortunately, I was unemployed since mid-November, which gave me tons of spare time for this silly stuff... but I start a new job on Monday, so I won't have so much time..,). If someone wants to spend time on this, I will be happy to test or whatever, though. Cheers, Álex
diff --git a/package/rust/rust.mk b/package/rust/rust.mk index 5d14fc6682..258daef331 100644 --- a/package/rust/rust.mk +++ b/package/rust/rust.mk @@ -38,6 +38,8 @@ endef HOST_RUST_POST_EXTRACT_HOOKS += HOST_RUST_EXCLUDE_ORIG_FILES +RUSTC_TARGET_NAME = $(RUSTC_ARCH)-unknown-linux-gnu$(RUSTC_ABI) + define HOST_RUST_CONFIGURE_CMDS ( \ echo '[build]'; \