CMake install overwrites libs of different configs about eastl HOT 10 CLOSED

This looks like a nightmare on *nix systems, such as linux or BSD, where libraries are expected to be installed to /usr/lib or in rare cases /usr/lib/$pkgname. This honestly seems like a very MSVC centric thing. In the case of MSVC, you can easily configure the output directory yourself.

Also this "Like I would expect other C++ libraries or SDKs to come with debug and release versions.", practically only happens with MSVC builds. For any other compilers you're required to build it yourself, and is still done by MSVC users because of MT/MD differences.
An option could be to output seperate debug symbols and a symbol map, which is enough information in most cases. If it isn't, the user can always build and install debug versions themselves.

from eastl.

Yes, @rparolin has to re-open the issue.
To chip in, as the guy who introduced the install target first, I think it's wrong in general to have multiple versions of the same library installed. The install target is either used as a dependency for another project (the reason why I added the install target), or installed for the whole operating system to use. In the former case, the EASTL should be compiled accordingly to the parent project settings, in the former case, a system wide installed library should never be debug. I think the change doesn't make sense at all.

from eastl.

Does it make sense to install debug libraries in this case?

from eastl.

Definitely, as I expect the output of the install step to be used as 3rd party dependencies in other projects. Like I would expect other C++ libraries or SDKs to come with debug and release versions.

If you see the install step as something that is not used in a development environment like a *nix system where other production ready software can be build from source, than this might not be appropriate.

from eastl.

I'm just unfamiliar with the concept of installing libraries in this way. I don't see a problem with adding this functionality to EASTL if its helpful to people. Feel free to send a PR.

from eastl.

Reopening, I don't understand why this has been merged as the OP didn't test his PR and this is breaking on unix-like systems, like I explained in my previous post.
${BUILD_TYPE} is wrong, to get the desired behavior, you need to write ${CMAKE_BUILD_TYPE}.
But again, this is not the correct solution, the better solution is the one you explained earlier and that is using a postfix.

Edit: Apparently posting a comment doesn't reopen the issue, I think rparolin has to do this.

from eastl.

I'm not sure how installations are used but EASTL doesn't offer binary compatibility between releases. I didn't a problem with including a feature that people thought was useful. It isn't great in my opinion that we can't/don't test it though. The argument could be made that we shouldn't support installations.

from eastl.

On Linux you're expected to do
pacman -S EASTL
g++ -std=c++11 file_that_uses_EASTL.cpp -lEASTL -o executable_using_EASTL
This breaks the ability to do that, now you need to -L/usr/lib/Release depending on where your distro installs it.
To retain compatibility between releases distros usually change the name of the library to something like EASTL.so.1.0 and then two symlinks which are name EASTL.so.1 and EASTL.so, and the order is EASTL.so->EASTL.so.1->EASTL.so.1.0. The linker will resolve the symlink at link time and will search for EASTL.so.1.0 when it runs.
Or we can simply link EASTL as a static library, so binary compatibility is out of the picture.
Either way, I think this shouldn't be included in EASTL, given the reasons given already.

from eastl.

Sorry for the trouble this caused!

'...as the OP didn't test his PR and this is breaking on unix-like systems ... ${BUILD_TYPE} is wrong, to get the desired behavior, you need to write ${CMAKE_BUILD_TYPE}.'

Apparently I did test the PR with VS and it does work, been using this for years before generator expressions where a thing. I wasn't aware that this doesn't work on single configuration generators like makefiles.
CMAKE_BUILD_TYPE is not an option since this is only defined on single configuration generators.

'...the better solution is the one you explained earlier and that is using a postfix.'
As stated earlier, I assume that renaming the libs is a breaking change. If this would be ok todo, this would be an option.

One other solution would be to put the install line with that change into an 'if(MSVC)' and keep the original got everything else.

from eastl.

I haven't seen any activity here. Can I close this issue?

from eastl.