On 31.12.2014, at 16:52, Nicolas George <geo...@nsup.org> wrote: > Le primidi 11 nivôse, an CCXXIII, Reimar Döffinger a écrit : >> >> Also I'm not arguing it's impossible, I'm arguing it's inconvenient. >> It's something like 2-3 additional steps for each library. > > How do you usually install a library? You are very vague about your use > case and usual methods. > > In particular, you did not explain what case you want to make simpler: > installing a library properly? using the library from the temporary build > directory to just test something? something else? Any of these cases can be > optimized, but not all the same way.
There is no "the case". I want to be able to easily hack and fix things when things go wrong or I happen to be in front of an unusual system. But it will be about quick hacks, so using one or several libraries from where I compiled them (as then you can test changes by just running "make" in each). > Anyway, in my administration experience, installing a library properly > requires a good dozen steps beyond make install to get things working > properly without breaking the system; the exact steps depend on what > administration tools are used: create a package, install with symlinks, etc. Just to make this completely clear: I never, ever, ever want to install anything that is not in a distribution repository. Exactly because it requires all those steps and you _never_ get it right. > Anything you want can be made to work easily with a configure that only uses > pkg-config, you just have to explain accurately enough what you want. I don't really care much about improving _one_ use-case, I'd ideally want all imagineable use-cases to "just work with a bit of hacking" - with empasis on minimal effort and number of steps, and steps that I can remember without documentation - cleanliness is not a concern at all (aka "hackability"). Especially those use-cases I do not yet know about. And pkg-config is a concern to me as I don't think I'll be able to fix issues with it quickly and easily when it fails. But just to have more than just hand-waving: a major specific use-case is compiling for MinGW using cygwin. To be more accurate I just tried it myself again, and most issues are not even related to pkg-config. It starts with --cross-prefix requiring to specify target os and arch (no, I really don't. I can just comment out this annoying error). Btw. configure just assumes HOSTCC==gcc to work without even checking that gcc is in the PATH... X264 configure is too stupid to figure out that using x86_64-w64-mingw32- very much doesn't mean it should use -m32... But after that I just need to add --extra-cflags=-I$HOME/x264 --extra-ldflags="-L$HOME/x264 -pthread" And it actually works even though x264 was configured with OpenCL (unintentionally actually). If I want to use pkg-config, I'd have to either install libx264 (also remembering to set the prefix, otherwise you might end up overriding your installed version in /usr/local, plus you have to re-run the whole build process) or set PKG_CONFIG_PATH _and_ edit the .pc file so it doesn't use whatever binaries exist in /usr/local instead (as this will not only affect x264 but all libraries). That might sound minor, but I consider that more than worth a few extra lines of configure code. Interestingly, the --pkg-config=/bin/true workaround needs you to be careful to actually put libraries in --extra-libs, not --extra-ldflags or the check will fail for static libraries, which is not completely obvious/100% matching how other configure implementations do it. > It is an alternative, but one you have to know about/think of and still is a bit of extra work. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
