The package is a binary package, should install in /opt.
*nvidia-cg-toolkit-2.1.0016 (04 Feb 2009) 04 Feb 2009; Markus Meier <maekke@gentoo.org> +files/80cgc-opt, -nvidia-cg-toolkit-2.1.0009.ebuild, +nvidia-cg-toolkit-2.1.0016.ebuild: version bump by Jean-Marc Hengen in bug #256525; install into /opt wrt bug #255867; old
Nice. Installing the library into /opt without accounting for building/linking against it breaks other packages.
please fix it up as it's causing build problems with everything that uses it.
(fix is to update env.d entry to include the new library path)
What about header files? They're also needed to build a client program, you know.
since nvidia-cg-toolkit lacks a proper config script or pkg-config file, those other packages will have to suck it up and add -I/opt/.../include in the ebuild via append-cppflags
*** Bug 258385 has been marked as a duplicate of this bug. ***
From what I gathered by asking different people other distros (eg Ubuntu, CentOS, ...) install Cg under /usr and thus is found without further measures by 3rd party developers. Gentoo is the odd one out; clients should not have to "suck it up", Gentoo should fix the breaking moving of Cg. A "binary packages go to /opt" policy may make sense for self-contained packages of binary applications, but clearly a blind move is not sufficient for libraries that need files to be found 3rd party scripts.
unless i missed something, nvidia-cg-toolkit is still binary only. that means it gets stuck in /opt.
You only missed the fact that Cg is a library, comes with header files (can they count as source?) which are needed by 3rd party clients, and that these clients are possibly prevented from building correctly due to the move of a dependency to an arbitrary location.
My main point is: you break existing software. If you can make it work by setting some magic environment variables or changing some files I don't mind /opt at all (note that the affected clients shouldn't changed, but only the environment!). If that isn't possible, well, that means /opt is obviously a broken-by-default choice of an installation location.
I'm not sure if gcc answers to INCLUDEPATH but certainly it works by setting CPPFLAGS="-I/opt/cg/include", which is exactly what the append-cppflags Mike pointed out before does. Yes it might not work out of the box for all the 3rd party software not in portage but for portage packages it'll just need to be fixed.
i didnt miss anything ... my previous comments still stand no one said it doesnt suck. but nvidia-cg-toolkit sucks for being binary-only.
(In reply to comment #13) > i didnt miss anything ... my previous comments still stand > > no one said it doesnt suck. but nvidia-cg-toolkit sucks for being binary-only. > So you're saying that all other packages which get broken by cg being put into /opt should have to "deal with it"? nvidia-cg-toolkit contains libraries and headers. Other programs need them. And emerging this software does not tell the system that Cg's hiding in /opt instead of /usr. The cause of the problem and the locus of the solution seem obvious to me... nvidia-cg-toolkit needs to be fixed by updating the environment or (global?) include paths, or by simply putting it into /usr -- *every other package* that needs it shouldn't have to be broken just so nvidia-cg-toolkit can be stuck into /opt out of spite because it's binary-only. That's simply unreasonable. So what's the hack to get clients working while this package gets its act together? CPPFLAGS="-I/opt/cg/include" ??
An issue with setting CPPFLAGS would be that a user might unintentionally "break" that hack - specifically, when he wants to build a 3rd party project and sets a custom value for CPPFLAGS suddenly things 'break'(Cg not being detected any more) because the Cg include path is overridden.
that doesnt make any sense. CPPFLAGS is *appended*, not set.
I mean something like: ~/third/party/sources $ CPPFLAGS="-Wblah" ./configure - Clearly this would replace CPPFLAGS and "disable" the Cg include dir hack.
(A more realistic example for CPPFLAGS would probably -std=something.)
i still have no idea what you're talking about. ebuilds will use append-cppflags to get the right path. there is no automatic CPPFLAGS setting outside of the ebuild, so there is nothing to "disable".
Oh, I was thinking of a setting in /etc/env.d/ ... Anyhow, no include paths adjustment outside ebuilds is even worse - that means 3rd party source code can not find Cg out of the box unless the user explicitly points to it!
i refer you again to comment #13
nvidia-cg-toolkit-2.1.0017 updates the env.d entry more so that it includes LDPATH/MANPATH as well
Why not make it not suck then? The only remaining issue is the include path one. Put a symlink into /usr/include or whatever and everything's fine.
i dont think we have any policy against that per-say ... it sounds reasonable enough
(In reply to comment #20) > Anyhow, no include paths adjustment outside ebuilds is even worse - that means > 3rd party source code can not find Cg out of the box unless the user explicitly > points to it! Not entirly true, for example to find it with cmake: FIND_PATH( CG_INCLUDE_PATH Cg/cg.h /usr/include /usr/local/include /opt/nvidia-cg-toolkit/include ) It's more a question, if 3rd party knows about it and its build script searches also in /opt/nvidia-cg-toolkit/include for it. I know it does suck and had also to change my build script, but I don't see that big problem with it. That's why there is a warning in the ebuild, that people can change their build script. That's more or less why a configure script exists, to do all this magic. And all ebuilds with the new location are marked as ~arch. The biggest problem not beeing in /usr/include, is that for c++, compiling with -ansi -pedantic will break the build unless -isystem /opt/nvidia-cg-toolkit/include is also added. This might not be true for 2.1.0017 anymore, since I didn't test that release yet. On the other hand, I don't have any problem with puting a symlink in /usr/include. Lets just do it the gentoo way.
Follow-up: see bug 261481 for an ebuild that makes Cg detectable by 3rd parties without requiring special measures or headers/libs search paths tweaking.
*** Bug 261481 has been marked as a duplicate of this bug. ***
