commit | c66403c33870855e98f291741c9da4659dbb8c17 | [log] [tgz] |
---|---|---|
author | Ed Tanous <edtanous@google.com> | Wed Sep 22 15:28:57 2021 -0700 |
committer | Ed Tanous <ed@tanous.net> | Mon Oct 04 18:32:55 2021 +0000 |
tree | 23d66bf80a4e6bab47c537eee178520f563ddabe | |
parent | 3c1504a3a73e69f1a2c13c82ce0da4014ee748f2 [diff] |
Change ordering of meson file Somehow the endif got messed up in our meson file, and seems to be causing problems for clang builds. It seems that all of our configure option checking got put under the "if gcc" branch, which it really shouldn't be, as options apply to all compilers. This commit simply moves all the debug, and option logic out into the primary scope, which makes things build correctly. Tested: Built with gcc in yocto, and gave the same expected options as previously (I specifically tested logging). Tested compiling in yocto with every combination of: DEBUG_BUILD_pn-bmcweb = "1" TOOLCHAIN:pn-bmcweb = "clang" All builds succeed Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I9b9da321615920942489d1b2f070b011b01b5efe
This component attempts to be a "do everything" embedded webserver for openbmc.
At this time, the webserver implements a few interfaces:
BMCWeb is configured by setting -D
flags that correspond to options in bmcweb/meson_options.txt
and then compiling. For example, meson <builddir> -Dkvm=disabled ...
followed by ninja
in build directory. The option names become C++ preprocessor symbols that control which code is compiled into the program.
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C buildir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in bmcweb/subprojects
.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Dbuildtype=debug ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja coverage -C builddir test
When BMCWeb starts running, it reads persistent configuration data (such as UUID and session data) from a local file. If this is not usable, it generates a new configuration.
When BMCWeb SSL support is enabled and a usable certificate is not found, it will generate a self-sign a certificate before launching the server. The keys are generated by the secp384r1
algorithm. The certificate
C=US, O=OpenBMC, CN=testhost
,SHA-256
algorithm.