In an ebuild, how do I control where files merge to?

[ChadJoan]

Hi folks.

I made a custom GCC ebuild with musl+dlang patches and other things (I called it gdc-4.9.4-r999.ebuild). Due to the potentially recurring difficulties involved with merging patches and troubleshooting quirks caused by running the dlang patches in an unfamiliar environment (hardened musl), I want to keep this completely separate from my system toolchain (e.g. so my system toolchain can upgrade more frequently). So I intend to have it use a different prefix like /usr/local/share/dcompilers/gdc, and I assigned EPREFIX="/usr/local/share/dcompilers/gdc" in my ebuild. However, when I run "ebuild gdc-4.9.4-r999.ebuild qmerge", I get file collisions: https://pastebin.com/knmdFNUe

How can I get the ebuild to place the colliding files into my chosen prefix?

Here is the output of "ebuild gdc-4.9.4-r999.ebuild configure": https://paste.pound-python.org/show/UyW4CPjEfMxcZqFo3csO/
My ebuild so far: https://paste.pound-python.org/show/SkdwZc2E0KhR4zTbkztl/

[cboldt]

[ChadJoan]

Ooooh, I think I see what's going wrong.

Now I have a different question: is there any way to modify EPREFIX within an ebuild such that it behaves as if it were assigned outside of the ebuild (ex: on the command line or in make.conf)? Or, in more specific terms, is there a way for me to modify EPREFIX within an ebuild such that all related values (ED and others) and state are updated appropriately?

That suggestion to read "man 5 ebuild" was actually pretty important here. The manpage seems to be much more up to date and/or specific than the webpage documentation I was reading.

I was reading this, this, and this.

The variables list on the webpage didn't mention the "Do not modify this variable." advice for EPREFIX that was present in the manpage, among other things. After reading that, I started to see the writing on the walls: I am updating EPREFIX, but ED never changes (and maybe other things too), so things like the toolchain eclass and the do* functions are getting incomplete or contradictory information. I ran an elog inside my ebuild to confirm.

I also never thought that the do* functions would help in my case. The "Install Functions Reference" only mentions that "${D} is automatically handled for all of these functions." From reading the variables list I understood that ${D} does not necessarily contain EPREFIX, so I conclude that the do* functions would send things to the wrong places (unless I added EPREFIX myself). And even if I could add EPREFIX to all of my do* functions, I'd have to ensure that my calls to do* would match what happens in toolchain_src_install(). After reading toolchain_src_install(), a sense of futility set in. But the description for "dodir" in the manpage mentions that dodir "Creates directories inside of ${ED}." So for dodir, actually everything should be fine as-is, if ED is set to the correct value (nope!). The others seem to use DESTTREE, and it seems like I can call "into" before calling toolchain_src_install() to set that to ${ED}/usr instead of /usr (as far as I can tell, toolchain_src_install doesn't call "into", so it should stick).

For experimentation's sake, I tried assigning ED to ${D%/}${EPREFIX} right after EPREFIX and in src_install() I tried calling "into" before calling toolchain_src_install(). It didn't work, and my elog still showed ED equaling some path that does not include EPREFIX. The methodology might be flawed, but I still feel like there is something about this that I don't yet grasp.