Build script to build liboqs

[charishma1407]

Purpose

This PR adds a build script (build_liboqs.sh) to simplify the compilation process for liboqs. The script automates the CMake configuration and build steps, making it easier for developers to build the library with common options.

Changes

• Added build_liboqs.sh script to automate the build process such as installing the dependencies and building.
• Script handles CMake configuration and compilation
• Provides a convenient wrapper for common build operations

Testing

The script has been tested locally and successfully builds the liboqs library.

Checklist

1. Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)?
   No - This PR only adds a build convenience script and does not modify any cryptographic algorithms.
2. Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API?
   No - This PR does not modify the algorithm list or any APIs. It only adds a build helper script.

AI Assistance

This contribution was created with the use of generative AI for builld-script-test.yml workflow

[baentsch]

Thanks for this PR @charishma1407 ! I like it as it makes life easier for users -- and is even more complete than the similar build script we have in the even more user-focused oqs-provider project.

That said, some questions:

• Who is the target audience for this? liboqs is a library that not too many users would (arguably, should :) build for themselves: One could argue that not having a build script excludes people from building the project that may have a propensity to "shoot themselves into the foot" having/wrongly using such script.
• Why no Windows support?
• Why no CI (testing)?
• Who would maintain this going forward (e.g., when new config options or algs get added/changed)?

[bhess]

Hi @charishma1407, thanks for the PR, I agree this is a useful convenience for users. To echo and build on @baentsch's last points: my main concern is long‑term maintainability. The script hard‑codes build options and algorithms but isn't exercised in CI, so as new options or algorithms are added it could easily drift out of sync. Adding CI coverage for the script, or otherwise deriving its options from a single source of truth, would help reduce that risk. On the other hand, this might add quite some complexity that counters the goal to simplify the build.

[baentsch]

Thanks @charishma1407 for adding thorough CI testing! This addresses those parts of the questions of @bhess and myself -- but it has one drawback: It requires an awful lot of compute cycles covering many --but surely not all-- current option-configs; also it will conceptually never be able to address the maintenance question (new config options added in the future).

So allow me to make a "wild" proposal: Would it be conceivable that a) at minimum this PR adds a feature to the script to issue a build-time warning if it discovers that any config file it depends upon and that are checked in (e.g., CONFIGURE.md, CMakeLists.txt) is more current than the build script? Even better (but I don't know whether it's possible) would be b) that such "build-script-out-of-date" check (in CI) triggers a Copilot "agent" creating an "AI-written" update to the build script taking the latest config options into account and ideally, even generating a PR for that?

[charishma1407]

Hi @baentsch and @bhess I made changes according to the comments

1. Created the workflow .yml file to run a CI test, and reduced it from 13 to 4 jobs to prevent the cycle.
2. Updated the build script with the stale code check in it.
3. As integrating it to copilot, I am not sure that copilot has the feature of creating the PR on its own.
4. Build script can make dynamically but one problem with that is it make the script more complex and also it looses it's simplicity.

[coveralls]

coverage: 82.302% (+0.007%) from 82.295% — charishma1407:charishma_build_script into open-quantum-safe:main

[baentsch]

Basically LGTM, see single comments (Yes, I should have grouped them into one coherent review :-()

[dstebila]

Have you tested the nix version? Claude says the following (but I don't use nix so I have no way of verifying whether this is a legitimate complaint or not):

nix develop spawns an interactive subshell and then falls through to cmake/ninja in the parent shell outside the nix env — the NixOS path almost certainly doesn't work as intended. Either exec nix develop -c ./build_liboqs.sh --inside-nix style, or document that users should nix develop themselves first.

[dstebila]

* Who would maintain this going forward (e.g., when new config options or algs get added/changed)?

I'm also worried about maintainability going forward -- not that the script is unmaintainable, just that we will forget to update it. I think the staleness check is a good step. But probably we need some documentation reminding us? Maybe in the PR template? Or somewhere else?

[baentsch]

@dstebila @xuganyu96 Did your concerns get sufficiently addressed by the new commits? How do you suggest moving this PR to conclusion?

[xuganyu96]

@dstebila @xuganyu96 Did your concerns get sufficiently addressed by the new commits? How do you suggest moving this PR to conclusion?

Upon re-reviewing, I find the maintenance overhead substantial, while the benefits are dubious. I think building liboqs is fairly straightforward: use cmake to generate build command, then use ninja to build. Build option discovery can be managed using cmake -LAN, so the help text in the build script is a duplicate of the descriptions already in the CMakeLists.txt files. My stand is to reject this pull request.

[bhess]

@dstebila @xuganyu96 Did your concerns get sufficiently addressed by the new commits? How do you suggest moving this PR to conclusion?

Upon re-reviewing, I find the maintenance overhead substantial, while the benefits are dubious. I think building liboqs is fairly straightforward: use cmake to generate build command, then use ninja to build. Build option discovery can be managed using cmake -LAN, so the help text in the build script is a duplicate of the descriptions already in the CMakeLists.txt files. My stand is to reject this pull request.

There is also ccmake, which I only recently learned about and have found quite useful for configuring CMake builds. I think it would be useful to add something about such "build simplifiers" to CONFIGURE.md.

I share the original concern regarding the long-term maintainability of the build script. I appreciate the work that has gone into this PR and the subsequent revisions, but I'm also not convinced that the additional maintenance burden is justified by the benefits, especially given the existing cmake configuration tools.

I do, however, find the dependency installation assistance quite useful. Would it be an option to keep just that part of the script?

[charishma1407]

Thank you everyone for taking the time to review this PR and share your feedback. As you have mentioned on the maintenance issue I'm going to go ahead and close this PR for now.
Thanks again for your time and guidance!