cmake support

[n-prat]

Is there any traction for CMake support?
I know about #552 (and #3237) but it is 2022 and I thought I would ask again.

Current pain points with the build system:

• no way to build a proper STATIC lib (= .a) with the current Makefile
  • "config-gcc-static" FAIL, and in any case it is not a static build
• the generated libyosys.so has a wrong SONAME(= $(LIBDIR)/libyosys.so) when it SHOULD be libyosys.so
  which makes it hard to properly package libyosys (without resorting to patchelf)
• no way to properly package/distribute as all paths are essentially hardcoded
• a Makefile is NOT made to handle dependencies; that is what autoconf is for
• configuring the Makefile requires generating a file on disk (Makefile.conf) which is less than ideal when
  integrating with CMake downstream projects

As it is pretty stupid to maintain two separate build systems, I would like to know if the maintainers are interested in migrating to CMake?

• if yes: I would gladly make a PR; in which case I would simply refactor all Makefile/Makefile.inc in the project
• if no: I will simply maintain a "quick and dirty" fork with CMake; It works fine but it is only for LIBYOSYS, it does run the tests, it does not handle the various options, etc

[jonnysoe]

@nathanprat,
Nice work on the initial CMake!

I just wanted to add on some of my observations on the difficult to package issue...

I found it the hard way as I move the library file around, but the linker just adamantly change the ELF's dependent libyosys.so SONAME regardless, I adjusted the PREFIX and found that it changes, until I realize something is wrong with the ELF as the linker will just take that SONAME.

As you've mentioned, tt seems that SONAME was hardcoded to LIBDIR which changes as we use different PREFIX, and by default it is always there - /usr/local. I should have stumbled on your pages earlier :)

Not sure if there are discussions or issues on this yet, perhaps this should be addressed as well?

[jonnysoe]

@nathanprat ,
How did you resolve the issue where static linking removed objects (translation units) where their variable declaration was unreferenced by other source codes?
A lot of the Pass::Pass registration functions are unreferenced, I saw this link mentioned about workaround in code or CMake:
https://www.cppstories.com/2018/02/static-vars-static-lib/

However this doesn't resolve anything when its super/wrapper library was in return linked by another executable or library

[n-prat]

Hi,

I did not, not really. For a while I was using -whole-archive cf #3241 and it worked fine but I end up packaging libyosys as a shared lib instead (with CMake CPack).

A proper fix would require touching the code and that's not something I want to do.

[jonnysoe]

@nathanprat ,
I've just read that the better option is to compile as object library and link as object instead of static library, it is less clunky than enable-whole-archive-link-disable.
I've tried various methods including modifying code, this seems more reliable with the exception that we do not chain-linking libraries, eg.

exe_A -> lib_A -> lib_B -> libyosys

I took it a step further with testing the object library, by compiling both libyosys and yosys targets, the compile time is no longer doubled

[ctormuthu]

+1 to this request.

Changing flags etc. in Makefile will require you to run make clean and then run make; this is problematic and needs careful handling on all platforms; moving to CMake is going to help Yosys be more modern and multiplatform with ease

[hcook95]

Apologies for reviving this old issue, but @n-prat, where could I find your initial efforts on CMake?

[n-prat]

Hi @hcook95

You can find the work in this repo https://github.com/Interstellar-Network/yosys/branches/all?query=cmake&lastTab=overview but this is really not "production grade".
Also, as you can see, this is not at all maintained, so I am not even sure it compiles with recent gcc/clang or CMake.

[KrystalDelusion]

@hcook95 there was some recent effort internally on a cmake conversion that you can find here: https://github.com/YosysHQ/yosys/tree/micko/cmake

It's still missing a few things before it can fully replace the current Makefile approach, but the intention is to continue the work later.

[whitequark]

From my perspective, a CMake buildsystem would be very much appreciated. Among other things it would enable development on Windows without MinGW or Cygwin.

[nickrallison]

I would say I would also really appreciate that, I'm working on Rust bindings for yosys and having the ability to natively output a libyosys.dll, or .dylib file would be really handy.

[mattyoung101]

Hi hi, I'd like to consider having a look at this myself to resume the work, as I'd like to add CMake and maybe eventually Conan to better handle deps.

It's still missing a few things before it can fully replace the current Makefile approach, but the intention is to continue the work later.

Is there any info on roughly where this was left off, and what precisely it is missing?