-
-
Notifications
You must be signed in to change notification settings - Fork 330
BUILD_ALWAYS causes install twice, to 2 dirs #625
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hey @DarthGandalf , thanks for testing it... I agree that change needs to be reverted. Raised a PR for that: #626 |
Hi @rizsotto @DarthGandalf ! I don't think the change needs to be reverted, nor do I believe bear is being installed twice. In my opinion, the issue lies in how CMake and Portage interact in this specific case. The project installs as expected, but an additional unstripped directory labeled "debug" appears. It seems that either Portage or the CMake cache used in Gentoo/Portage is causing CMake to install a debug version of the subproject alongside the main project. I can't reproduce this issue with my CMake setup, which leads me to believe it may be related to unseen files in this bug report, such as the toolchain file or the CMake cache used with Portage. |
"debug" is not the problem, it's there because I'm using FEATURES=splitdebug mnt/ is still present if I disable this feature:
|
Can this be different CMake versions? |
cmake 3.31.5 here |
I am sorry, but I don't see repeated files here! I see CMake installed the correct files under By the way, I am using CMake 3.31.6. |
no worries
This whole subtree I'm showing is under /mnt/portagetmp/portage/dev-util/bear-3.1.6 - the "image" subdir of it is what would be installed to / later. The point is, "make install" (or "ninja install"?) now copies the staged copy of ExternalProject to DESTDIR, while it didn't do that before addition of BUILD_ALWAYS. I don't know why it does that. |
you can see in the log attached how this ExternalProject is installed:
|
What is the value of |
PORTAGE_TMPDIR is Yes, it works when I remove BUILD_ALWAYS, see https://github.com/gentoo/gentoo/pull/41304/files#diff-b3fcdcbbd9014dbf08a087cb1f6bf2e86a9c9bc3832d2038242962571c59adb4 |
@rizsotto what was the reason to use ExternalProject instead of |
Could you share all the configuration settings that Portage might be applying under the hood? I'd like to reproduce the issue locally. I strongly believe this is not related to Ultimately, this decision rests with @rizsotto, as he is the maintainer of Bear. However, the current configuration has been highly beneficial to us, our CI system, and likely any other developer who has recently modified the C++ codebase. Before the commit we are now proposing to revert, any changes made under |
How did you notice that? Because I don't use a custom toolchain nor a cache :) Here's my /etc/portage/make.conf
and emerge --info
|
From
|
That's not a cache. The gentoo_toolchain.cmake is just how Portage handles cmake projects, to use the correct compiler.
|
|
Please, post |
|
I still can't reproduce the issue. What is the value of I ask you to please run Portage with I see no changes in the generated files when trying to reproduce the issue. Thus, I believe the issue is with Portage and not with Bear enabling or disabling |
The cmake eclass doesn't set CMAKE_INSTALL_MODE to anything |
@DarthGandalf @inaki-amatria thanks to look into this! I do appreciate that you spend time to find a solution for this. I am not really an expert on CMake... I still try to put my head around why would the
|
Would you be ok with replacing ExternalProject with add_subdirectory? |
Thank you for your time and effort in investigating this, Alexey and László. Based on the available evidence, this issue seems specific to Portage or the build recipe for Bear under Portage. As it has been pointed out, we cannot reproduce the issue elsewhere, and Alexey, I understand that this behavior is undesired, but rather than modifying Bear to accommodate Portage, it might be more effective to investigate why Portage is causing repeated installation of targets. This may not be an isolated issue, as other projects under Portage could be affected in similar ways. By pinpointing the root cause, you could help remove unnecessary patches across multiple projects, saving Portage maintainers significant effort in the long run. I would recommend trying to create a minimal reproducer with CMake and Portage to isolate the issue. Let us know if we can assist in that process. |
To me this is the right approach. The usage of ExternalProject is highly unusual. |
I've made the decision to use Long term, I am planning to replace the C++/CMake with rust/cargo. (ETA for that is in May this year.) I would like to have no trouble to package the existing version. If that means I have to revert the |
Well, it shouldn't be too hard. But if it's going to be replaced with rust in just 2 months, probably that doesn't worth the effort. |
Describe the bug
I'm maintainer of Bear in Gentoo, and tried to package version 3.1.6, but some files are now installed twice:
Note the mnt/ subdirectory
As it was added in #607 CCing @inaki-amatria
To Reproduce
Steps to reproduce the behavior:
Just try to build?
Expected behavior
install shouldn't install an extra copy of files
Environment:
Additional context
configure
script]bear -- make
) with extra verbose log switches (e.g.bear --verbose -- make
) and send the output of it, that would help a lot.Attaching both versions for easy comparison
3.1.5-build.log
3.1.6-build.log
Before you send...
README.md
file orman bear
?The text was updated successfully, but these errors were encountered: