The introduction of a new ARCH variable was unnecessary, as ARCH already
exists. That said, the .zip provided for PROTOC isn't a natural fit
here either, as upsream uses `aarch_64` rather than `aarch64`.
In stead, I've used `notdir` to get the filename from the
already-defined `PROTOC_URL`.
Signed-off-by: Jonathon Anderson <janderson@ciq.com>
This allows `make` and `make all` to avoid unnecessary repeat builds,
and saves automatic generation of man pages for `install`.
Signed-off-by: Jonathon Anderson <janderson@ciq.com>
Using a `config` variable in target dependencies allows the underlying
targets to be referenced properly, rather than passing through a "phony"
`config` target. This allows dependent targets to not have to re-run if
their dependencies have remained static, as expected.
Signed-off-by: Jonathon Anderson <janderson@ciq.com>
The `all` target should be the default for make; but placing it after
the `include` directives allowed the targets within the included files
to take precedence.
Moving `all` before the `include` directives restores it to default
status.
I also used this opportunity to restore the `build` target as the
defining target, and then just set up a dependency between `all` and
`build`.
Signed-off-by: Jonathon Anderson <janderson@ciq.com>
The previous PR #890 introduced a `Defaults.mk` target for defining
default variables for future calls to `make`. This functionality was
already present in a different form, but this new "real" target had an
unintended side-effect of causing the target to be called automatically
at reference, even the optional reference `-include Defaults.mk`. This
is undesirable as it causes the generation of defaults even during a
`make clean`.
This commit resolves these issues and further refactors the Makefile,
building on the work in #890, but with additional understanding:
* Convert the `Defaults.mk` target to the "phony" `defaults` target,
preventing automatic generation
* Refactor and split `clean` targets
* Update `cleanvendor` to reflect `OFFLINE_BUILD`, similar to the
`vendor` target
* Move "tools" targets into `Tools.mk`
* Add `ARCH` to `Variables.mk` for architecture-specific actions
Signed-off-by: Jonathon Anderson <janderson@ciq.com>
Every struct in a NodeConf with `lopt:"foo" set is now added as a
command-line flag with the RecursiveCreateFlags call. For maps a struct
with the key UNDEF is added so that it can be parsed out.
As the flags for the command-line need variables which hold the values,
for every map an element map[UNDEF] is added. When now calling the
internal add, these map element can be filtered out and replace by the
given name. (e.g., --netname)
* rewrote node/profile add for recursive functions
* rewrote node/profile set for recursive functions
* rewrote node/profile list for recursive functions
Signed-off-by: Christian Goll <cgoll@suse.com>
when transforming a NodeInfo struct to a NodeConf (set the NodeConf from
the NodeInfo) nested structures were seperately handled. This means a
there were seperate handles for e.g *Netdevs and *IpmiConfig. The new
getter traverses through the datastucture and sets the right value for a
Entry struct, but calls itself again if a Pointer is detected.
This adds the posiblity to add new nested structures to NodeConf and
NodeInfo without the need of seperately handling them in the transformer
functions.
Signed-off-by: Christian Goll <cgoll@suse.de>
When transforming a NodeConf struct to a NodeInfo (get the NodeInfo from
the Nodconf) nested structures were seperately handled. This means there
were seperate handles for e.g *Netdevs and *IpmiConfig. The new getter
traverses through the datastucture and sets the right value for an Entry
struct, but calls itself again if a Pointer is detected.
This adds the posiblity to add new nested structures to NodeConf and
NodeInfo without the need of seperate handling them in the transformer
functions.
Signed-off-by: Christian Goll <cgoll@suse.de>
