On 2022-03-22, Kenny McCormack <
gaz...@shell.xmission.com> wrote:
> In article <t10hp1$ttj$
1...@dont-email.me>,
> Janis Papanagnou <
janis_pa...@hotmail.com> wrote:
>>On 17.03.2022 22:41, Kaz Kylheku wrote:
>>> Don't want @include? Use #include!
>>
>>Doesn't @include do more than just lexical text replacement?
>
> It is hard to tell what exactly is the point of this "cppawk" thing.
> As usual, OP is long on "where" and "how", but not so hot on "why".
The "why" is very open ended. An aspect of it is "why not", as well
as exploration: discover the "why".
> That said, I do kinda see how it (using the C preprocessor to do the heavy
> lifting) is more powerful than the (rather basic) @include facility built
> into GAWK. But of course, is it more powerful enough to justify anyone
> other than OP adopting it ("it" being "cppawk") into their workflow?
> Unclear.
Depends on dependencies too.
Imagine I say to you, I have this nice cppawk program. Oh, but it's
written in Rust, just install Cargo and pick up the cppawk crate ...
Oh good grief.
But a tiny shell script; what the heck?
Possible reasons for using it:
1. You know how to use that preprocessor, and are doing work on a system where
you can count on it being installed. Use what you know.
(I will likely be using it in situations when Awk gets used as part of build
tooling. Reason being: cpp being installed is a given if you're compiling
stuff with GCC or Clang. Also, in that environment, C preprocessing is much
more familiar to devs than Awk; I don't have to worry about anyone not
understanding the preprocessing bits of a piece of code. The cpp dependency
is not too bad, except in embedded systems: but see point 8).
2. It makes some things easy, like making a program out of multiple
files, which easily find each other in the same directory or relative
path. Or macros, for some syntactic sugars.
3. Potentially works with different Awks. There is the possibility of using
#ifdef to make code work on different Awks from one file. (The default
cppawk installation uses gawk, and also defines __gawk__ 1 that you can
test for.)
4. Comments. Awk has no comments that don't end at the end of
the line; cppawk gives you /*...*/.
5. Temporarily disabling code with #if 0 ... #endif rather than
fiddling with hash marks.
6. Exploration: Awk is syntactically C like, but not C: what
implications does that have for writing macros? You can discover some
new-ish techniques, though it won't be earth-shattering.
7. Weird access to some host attributes intended for C:
$ cppawk '#include <limits.h>
BEGIN { print PATH_MAX, ULONG_MAX }'
4096 214748364701
this sort of thing looks mildly useful in devops land.
8. cppawk --prepro-only will generate the preprocessed output for
you, which can run on a system that has no preprocessor, such
as an embedded board that has only BusyBox Awk.
Using -Dfoo=bar macro definitions with --prepro-only and
preprocessing conditionals/macros lets you generate different
versions of the program.
for conf in this that other ; do
cppawk --prepro-only -Dconfiguration=$conf > $conf.awk
done
now I have a this.awk that.awk and other.awk based on the
same source, but somehow usefully different.