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.269% (-0.001%) from 82.27% — charishma1407:charishma_build_script into open-quantum-safe:main