Build: port to cmake

[omor1]

Use cmake rather than homespun Makefiles. Includes some other fixes, notably in src/pm.c: aggressive IPO/LTO was eliminating several of the externally-visible lc_pm_xxx functions since it wasn't aware they were externally visible (go figure).

[danghvu]

feel free to merge to v2 if this is ready, do you have permission to merge ?

[omor1]

I wanted you to have a chance to look it over before I merged, just in case I missed anything. I'll use cmake for v21 too soon.

[danghvu]

My only request is that: try to have both Makefile and cmake if possible but maybe you can try to do that in v21

[omor1]

I think I had an issue that caused me to remove the Makefiles; I use config.h.in to configure config.h, but the build was finding the old config.h in the source. I think I might know the solution, I'll test it and see if it works. That would restrict the build to be out-of-source for cmake, but that should be done anyway.

[omor1]

Actually, I remember the problem with config.h now: files in the same directory that #include "config.h" will find it first rather than the actual configured header in the build directory. Let me see what I can do to fix this...

[danghvu]

How about rename it to config.h.mk and then do a “cp config.h.mk config.h” if using Makefile?

…

On Thu, Apr 2, 2020 at 7:48 PM Omri Mor ***@***.***> wrote: Actually, I remember the problem with config.h now: files in the same directory that #include "config.h" will find it first rather than the actual configured header. Let me see what I can do to fix this... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIZNSUFH5KXNQQ57WPMP3TRKVFBLANCNFSM4LGA5QBA> .

[omor1]

My current solution was to just plop it in the top-level directory, which I don't include in the cmake build (but which is in the Makefile), but yours probably works better.