ok, Ive sent you a PR, which now builds with cmake
(for now I have not removed jucer files)
Note:
Juce is now included with a submodule so you should do
then its just
git submodule update --init --recursive
mkdir build; cd build
cmake ..
cmake --build .
or of course just load the project using CLion 
BUT there is one small issue…
the EigenCore is not linking currently… the reason is what you have done with EigenLite !
basically the approach you have taken, using binary library files, is not the way it should/needs to be done.
I did try to link it statically, but CMake was not playing ball…
(or it might be the Juce targets specially, as the cmake options that should work don’t)
BUT
I didn’t continue, because as I said, this is not really the way to make it work
so correct approach is:
a) use submodules
so as Ive done with juce, create a submodule that points to my EigenLite project
b) just include the EigenLite project into this project.
there is a CMakeFile that already in EigenLite that will neatly bring this is.
this requires a couple of things…
i) you revert to using my EigenLite i.e. one without changes
I don’t see this as an issue, as Ive included your pull requests.
you could use your own fork , but you should aim to keep it inline with mine… having forks with such a small user base, is frankly not a good idea 
so we really should aim to combine these.
ii) static library
perhaps this is why you are using a fork?
but we can easily modify the EigenLite CMakeFile to support both dynamic libraries and static build - simple flag setting would work.
thats said, Im not sure why you’d care… given the picodecoder has to be a dynamic lib. for reasons I mentioned above, so one or two dynamic libs is really not an issue.
why is this approach better?
well apart from have a more consistent build, it also makes cross-platform builds much easier, since you are building EigenLite from source.
SO… if you building on macOS arm, macOS intel, or windows , or linux , it will all just build.
if you go the binary library route, you’d have to build all the different variations, and alter the link to make sure you pull in the correct version - then IF EigenLiite updates, you have to build them all again.
this way ‘it just works’ ™ , as you can simply do a pull from EigenLite subdirectory and bobs your uncle… new build is created where nessary.
also as I mentioned above… for licensing purpose, if you are using JUCE under GPL (to avoid the banner ;)), you cannot include binary libraries without source - thats part of GPL.
bare in mind EigenLite is GPL, because the EigenLabs code it uses is GPL… so it has to carry forward
id also point out (legally) you are probably on ‘shaky’ ground embedding the ihx files into your binary
anyway , that s why I didn’t fix the static linking, as its just creating more trouble that its worth.
on the other hand, I didn’t want to move back over to using EigenLite without chatting to you first about it.
but using an EigenLite submodule, is the way I would do this
( * ) I know , I know, no one cares… it’s easer for the end user. etc etc,
but as an open source dev, I do respect licenses etc, EigenLabs were kind enough to open source the code, which made all of this possible… so I personally respect it - but its your decision.
