[eigen3] installs headers in the wrong place since recent merge

[dada2048]

Host Environment

• OS: Windows
• Compiler: VS2019
• vcpkg: HEAD of the master branch

To Reproduce
./vcpkg install eigen3
and try to compile something that does #include <Eigen/Dense>

Failure logs
C1083: Cannot open include file: 'Eigen/Dense': No such file or directory

Additional context
I use user-wide integration with MSBuild.
I use multiple packages in my project. They all worked before #12229 was merged on August 28th. After that date, eigen3 stopped working but the rest are still fine.
Reverting the eigen3 part of that merge fixes it (though it probably breaks something with that other package; I didn't test that).
Another workaround is to #include <eigen3/Eigen/Dense> but that's not how the library is supposed to be used.
Yet another workaround is to add $(VcpkgCurrentInstalledDir)include/eigen3 in the vcpkg.targets used by MSBuild.

[cenit]

Eigen3 portfile was manually duplicating files from include/eigen3 to include/ (not an ideal solution, you might agree)

The cmake part was half broken before (some ports were detecting it in include path, others in include/eigen3) and is very well tested in CI now. The VS integration OTOH I am sorry was never tested by me. Is it really inconvenient for you to add include/eigen3 to the include path in vs?

[Neumann-A]

Eigen3 portfile was manually duplicating files from include/eigen3 to include/ (not an ideal solution, you might agree)

@cenit I was wondering why your PR was merged with those changes because the MSBuild issue was apparent. Maybe installing a symlink would be a better way to allow the MSBuild integration to work or only allow the copying on Windows.

[dada2048]

It's not a big inconvenience as far as workarounds go because it should only be temporary. Only if you're telling me it won't be fixed does it become a bigger deal.

I agree it's not ok to have all the includes duplicated and you may very well have removed the right set (apt install libeigen3-dev, which vcpkg emulates to an extent, also puts the files in /usr/include/eigen3/Eigen).

Still, the design of vcpkg seems to be that you install packages and they immediately work without having to configure include and library paths anywhere. It does that for the other packages I use so I expect a solution will have to be found, though I don't know what it'll look like.

[cenit]

Yeah you're right about the "immediately work", and that would be still true if you were using the CMake toolchain.

I am not really sure about sustainability of the other setup, the one you're using, which relies on autolinking and putting all files in include in order to have them there, without any file containerization. We already have many ports that install conflicting files (same names) and as such are installed in a subdirectory inside include in order to let them live together. Those ports are broken by default in your setup, but work perfectly with CMake.

That might not exempt my faults because Eigen include files are very peculiar in naming and are not colliding with any other, but still it's the idea I'm trying to explain.
So, IMHO, while I'm not saying that it won't be fixed (it will be for sure), I'm trying to say that you are relying on a setup which is going to be abandoned sooner or later (again, IMHO) because it's unsustainable by design.

[dada2048]

How are those libraries with conflicting files installed on linux? I assume they get separate directories and vcpkg should be using the same names. That would keep vcpkg/installed/include looking the same as /usr/include.

Are the users of those packages (who also use MSBuild) adding compiler options manually? I haven't encountered this issue before but if it's common maybe this isn't considered a bug.

Maybe the coming manifest feature can include a way for MSBuild to find the pkgconfig of the requested packages and pick up the needed properties there automatically (similarly to what CMake can do).

[traversaro]

How are those libraries with conflicting files installed on linux? I assume they get separate directories and vcpkg should be using the same names. That would keep vcpkg/installed/include looking the same as /usr/include.

At least in the case of eigen3 on Debian-based system, the expected include directory to pass to the compiler is: /usr/include/eigen3, see https://packages.ubuntu.com/focal/all/libeigen3-dev/filelist .