use HOST_{CC,CFLAGS} for icons generator

[N-R-K]

when cross compiling the icons generator need to be built and run on the host machine and not the target one. HOST_CC seems to be a somewhat common convention so use this and be explicit about the host vs target compiler.

also drop LDFLAGS from generator.

Closes: #2142

[PPN-SD]

HOST_CC is for the cross-compiler, binary is run on the target system
BUILD_CC is for the native compiler, binary is run on the build system (typically tools like icons-hash-gen)

[N-R-K]

HOST_CC is for the cross-compiler, binary is run on the target system BUILD_CC is for the native compiler, binary is run on the build system (typically tools like icons-hash-gen)

Is there any convention for this? I looked it up and both of these say HOST_CC is the native/host compiler:

• https://landley.net/writing/embedded/cross.html
• https://android.googlesource.com/platform/external/bc/+/refs/tags/android-11.0.0_r42/manuals/build.md

[PPN-SD]

Is there any convention for this? I looked it up and both of these say HOST_CC is the native/host compiler:

As you pointed out, not really.

From Debian:
The build architecture is the architecture on which debian/rules is run and the package build is performed. The host architecture is the architecture on which the resulting package will be installed and run.
[...]
where * is either BUILD for specification of the build architecture, HOST for specification of the host architecture or TARGET for specification of the target architecture.

[PPN-SD]

That’s why I propose a proper target for the native tools and let the distribution set the correct native compiler environment.

[N-R-K]

The linux kernel also seems to use HOSTCC (without the underscore) for the build/native machine. It's unfortunate that debian uses conflicting term but I think linux kernel is a better example for us to follow.

That’s why I propose a proper target for the native tools and let the distribution set the correct native compiler environment.

Both cases will require the builder to know that cross-compilation requires some special steps. Since neither will work "automatically" I'd rather be explicit.

[PPN-SD]

android keeped the kernel terms, it seems consistent to me.
That's not Debian. For GNU-based systems I know, host means the target machine, so HOST_CC is the cross‑compiler.

[PPN-SD]

Please refer to: https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html

[N-R-K]

Ok so gnu uses the same term to mean different thing than linux. We can go with the linux terms.

[N-R-K]

@jarun this should be good to merge.

[PPN-SD]

So you decide to ignore what is the common practice ?
Add wrong vars without a proper target makes no sense but I wont insist anymore.

[N-R-K]

So you decide to ignore what is the common practice ?

Except that there is no common practice. Different projects use different vars for the same thing. nnn follows linux kernel coding style so it's not unprecedented to adopt linux kernel terms as well.

without a proper target makes no sense

I see no benefit separating the header and the generator. If you build the generator with O_NERD=1 it will only output nerd icons, not emoji ones for example. So it's not like you could build the generator once and have it output multiple headers.

If you insist on doing it in two steps, you can still do it. You'd just target the header file instead of the generator:

$ make O_NERD=1 CC=${host-cc} src/icons-generated-nerd.h
$ make O_NERD=1 CC=${cross-cc}

But with an explicit host cc variable it becomes one step:

$ make O_NERD=1 HOST_CC=${host-cc} CC=${cross-cc}

[PPN-SD]

Except that there is no common practice. Different projects use different vars for the same thing. nnn follows linux kernel coding style so it's not unprecedented to adopt linux kernel terms as well.

build is native, and host is the machine where the binary will run. That is standard practice. Comparing this to the Linux kernel doesn’t make sense.