Get a proper command line parser

[widlarizer]

Feature Description

Currently, we use a homemade getopt in kernel/driver.cc. We have lots of single letter options so to add a feature I want a full word option lke --option=value, which we don't support currently, which is probably why we have many single letter options in the first place.

Let's move to a boring, normal solution like cxxopts (C++11) or argparse (C++17). Our current demands will be met by just about anything, so we have to think about what we want from command line argument parsing in the future to pick something

[widlarizer]

This will have to respect #3973 and other possible quirks

[Apteryks]

Currently cxxopts provided by the system cannot be easily used because of strange include paths:

[  2%] Building kernel/celledges.o
kernel/driver.cc:22:10: fatal error: libs/cxxopts/include/cxxopts.hpp: No such file or directory
   22 | #include "libs/cxxopts/include/cxxopts.hpp"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:758: kernel/driver.o] Error 1
make: *** Waiting for unfinished jobs....

I guess this is bundled as a submodule? It'd be cleaner if the 3rdparty stuff was kept outside the sources and the build system considered their location, to keep the normal

#include <cxxopts.hpp>

In the source, which would work with a system provided cxxopts library.

[widlarizer]

Yes, it's a submodule. Here's why:

• we would lose control over whatever cxxopts the user is going to get from their package manager
• therefore yosys of the same version may then behave in various ways
• it would also be more difficult for users to set up a build environment
• cxxopts is a single header file, there's miniscule or negative disk space savings on relying on system package managers
• build systems with package management support, such as cmake, are an alternative to system packages. Yosys isn't a cmake project
• languages with integrated build systems with package management support, such as cargo for rust, are another one. Yosys is written in C++

If you're encountering this error, is this a result of deliberately desiring to use a system packaged cxxopts? It's not the only submodule. Submodules aren't generally a roadblack for building yosys for package distribution based on what I've seen on AUR and nixpkgs. If you're building yosys from the release sources, the yosys.tar.gz file actually contains all submodules properly vendored.

[Apteryks]

Thanks for the explanation. The Guix package yosys currently takes its source from git, and by default we don't fetch submodules as these are often for bundled libraries which we prefer to package separately as shared libraries and dynamically link to them. I believe other GNU/Linux distributions such as Debian also have that policy/preference.

The upstream vs downstream control over dependencies is a hot topic these days with cargo and the likes, but shared library-based GNU/Linux distributions typically favor having their say over the libraries used, to ease maintenance and for transparency, among other benefits. Sure, the behavior may be a bit different if the version is not the exact one used in yosys, but the other hand it'd be consistent across all the cxxopts-using packages of the distribution, and if an improvement is made to it all would benefit from an upgrade.

Even if this project uses Make rather than a full-featured build system as Autotools or CMake, pkg-config can be used to determine if a system-provided library meets the requirements of the project for some libraries; cxxopts ships a cxxopts.pc file for example.

For now, this simple substitution (patching the source) allows the headers files from the system to be found, as part of the Guix package definition:

              (substitute* "kernel/driver.cc"
                (("^#include \"libs/cxxopts/include/cxxopts.hpp\"")
                 "#include <cxxopts.hpp>"))

Thank you!

[whitequark]

but shared library-based GNU/Linux distributions typically favor having their say over the libraries used

This is not a shared library, but a header-only library.

[Apteryks]

but shared library-based GNU/Linux distributions typically favor having their say over the libraries used

This is not a shared library, but a header-only library.

True! Even in this case, it isl nice to be able to maintain a single copy (or a few, if we must) used by other software of a distribution instead of having 3rd party bundled as sources in a potentially large number of leaf packages.

[QuantamHD]

Very supportive to the challenge of package maintainers, but imo as a Yosys user I would generally prefer a more reproducible build with dependencies clearly defined.

Shared objects and OS installed headers have never really made things easier for me personally, but that is just my experience.

Obviously up to the Yosys maintainers, but I would optimize for users and developers before other needs if it were me.

[Apteryks]

Typically, if bundled 3rd party is the preferred means of building, the build system would default to do that. A flag can be used to opt for system-provided libraries.

To image:

make    # as usual

make WITH_SYSTEM_LIBS=1    # different behavior for distro packagers

Tries making use of system libraries. Can be lenient and fallback to the bundled versions with a warning.