Opened 10 years ago
Closed 2 years ago
#4197 closed defect (wontfix)
libspeex detection is broken on systems without pkg-config
| Reported by: | Carl Eugen Hoyos | Owned by: | |
|---|---|---|---|
| Priority: | important | Component: | build system |
| Version: | git-master | Keywords: | libspeex regression |
| Cc: | gajjanagadde@gmail.com | Blocked By: | |
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
libspeex detection is broken on systems without pkg-config since 621d4089
Change History (30)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Look at the commit message, this is completely intentional.
And for this one, I must say I fully agree with Luca: pkg-config has been around for years and is nowadays an essential element of a build environment. Maintaining ways of overriding it is IMHO wasted time, because it is redoing in FFmpeg work that is already been done by the library upstream, and not redoing better. Fixing the few cases where pkg-config is badly used in the build system, if there are still any, is much better spent time.
I support closing this as wontfix, and officially announcing that all similar complaints will be closed with the same answer: install pkg-config.
follow-up: 4 comment:3 by , 10 years ago
(I did not want to imply it wasn't intentional, just that I had forgotten about this.)
This is a (very) bad regression and we should do the same as for x264.
I will try to produce a patch this weekend.
Several operating systems don't install pkg-config by default. Additionally, I believe it is very useful to link an external library without installing it first.
follow-up: 5 comment:4 by , 10 years ago
Replying to cehoyos:
This is a (very) bad regression and we should do the same as for x264.
I strongly object to that. It makes the build system slower and harder to maintain for no benefit.
Several operating systems don't install pkg-config by default.
Several operating systems don't install a C compiler by default. And most operating systems do not install the development files for the libraries by default.
If people need pkg-config, they install it, just as the libraries they want and yasm and texi2html and...
Additionally, I believe it is very useful to link an external library without installing it first.
Please share the basis for that belief.
follow-up: 10 comment:5 by , 10 years ago
Replying to Cigaes:
Replying to cehoyos:
This is a (very) bad regression and we should do the same as for x264.
I strongly object to that. It makes the build system slower and harder to maintain for no benefit.
I am willing to take the burden.
Several operating systems don't install pkg-config by default.
Several operating systems don't install a C compiler by default. And most operating systems do not install the development files for the libraries by default.
What I meant was: On several operating systems, after you install the compiler and the necessary libraries and headers, there is no pkg-config and this configuration was supported by FFmpeg for many years. Removing this support means introducing a regression.
If people need pkg-config, they install it, just as the libraries they want and yasm and texi2html and...
Not everyone who wants to compile FFmpeg can install on the target system.
Additionally, I believe it is very useful to link an external library without installing it first.
Please share the basis for that belief.
You misunderstand: When I test, I never install the libraries but always link them from the build directory. (The basis is just my workflow for testing FFmpeg because of user reports that include using external libraries.)
follow-up: 7 comment:6 by , 10 years ago
You can use pkg-config without installing pkg-config itself or the libraries just fine.
comment:7 by , 10 years ago
Replying to heleppkes:
You can use pkg-config without installing pkg-config itself or the libraries just fine.
I prefer not to use it: I consider it difficult to use and it does not always work the expected way, remember that I often have to test old versions of external libraries.
comment:8 by , 10 years ago
@cehoyos:
Please paste your uncut configure output and relevant section of config.log to make this a valid ticket. Thank you.
comment:9 by , 10 years ago
$ git log -1 --oneline f622ff1 avfilter/vf_boxblur: avoid one addition per line
$ dash configure --enable-libspeex ERROR: speex not found using pkg-config If you think configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the problem to the ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net. Include the log file "config.log" produced by configure as this will help solve the problem.
check_pkg_config speex speex/speex.h speex_decoder_init -lspeex false --exists --print-errors speex ERROR: speex not found using pkg-config
It worked fine before 621d4089
$ git log -1 --oneline 8b1e920 Merge commit '259fe7280d0b63dc7a8ff017d44f26d3a84cfde8'
$ dash configure --enable-libspeex install prefix /usr/local source path . C compiler gcc C library glibc ARCH x86 (generic) big-endian no runtime cpu detection yes yasm yes MMX enabled yes MMXEXT enabled yes 3DNow! enabled yes 3DNow! extended enabled yes SSE enabled yes SSSE3 enabled yes AVX enabled yes XOP enabled yes FMA3 enabled yes FMA4 enabled yes i686 features enabled yes CMOV is fast yes EBX available yes EBP available yes debug symbols yes strip symbols yes optimize for size no optimizations yes static yes shared no postprocessing support no new filter support yes network support yes threading support pthreads safe bitstream reader yes SDL support yes opencl enabled no texi2html enabled yes perl enabled yes pod2man enabled yes makeinfo enabled yes External libraries: bzlib libspeex zlib iconv xlib Enabled decoders: aac bink gsm_ms aac_latm binkaudio_dct h261 aasc binkaudio_rdft h263 ac3 bintext h263i ac3_fixed bmp h263p adpcm_4xm bmv_audio h264 adpcm_adx bmv_video h264_vdpau adpcm_afc brender_pix hevc adpcm_ct c93 hnm4_video adpcm_dtk cavs huffyuv adpcm_ea cdgraphics iac adpcm_ea_maxis_xa cdxl idcin adpcm_ea_r1 cinepak idf adpcm_ea_r2 cljr iff_byterun1 adpcm_ea_r3 cllc iff_ilbm adpcm_ea_xas comfortnoise imc adpcm_g722 cook indeo2 adpcm_g726 cpia indeo3 adpcm_g726le cscd indeo4 adpcm_ima_amv cyuv indeo5 adpcm_ima_apc dca interplay_dpcm adpcm_ima_dk3 dfa interplay_video adpcm_ima_dk4 dirac jacosub adpcm_ima_ea_eacs dnxhd jpeg2000 adpcm_ima_ea_sead dpx jpegls adpcm_ima_iss dsd_lsbf jv adpcm_ima_oki dsd_lsbf_planar kgv1 adpcm_ima_qt dsd_msbf kmvc adpcm_ima_rad dsd_msbf_planar lagarith adpcm_ima_smjpeg dsicinaudio libspeex adpcm_ima_wav dsicinvideo loco adpcm_ima_ws dvbsub mace3 adpcm_ms dvdsub mace6 adpcm_sbpro_2 dvvideo mdec adpcm_sbpro_3 dxa metasound adpcm_sbpro_4 dxtory microdvd adpcm_swf eac3 mimic adpcm_thp eacmv mjpeg adpcm_vima eamad mjpegb adpcm_xa eatgq mlp adpcm_yamaha eatgv mmvideo aic eatqi motionpixels alac eightbps movtext alias_pix eightsvx_exp mp1 als eightsvx_fib mp1float amrnb escape124 mp2 amrwb escape130 mp2float amv evrc mp3 anm exr mp3adu ansi ffv1 mp3adufloat ape ffvhuff mp3float ass ffwavesynth mp3on4 asv1 fic mp3on4float asv2 flac mpc7 atrac1 flashsv mpc8 atrac3 flashsv2 mpeg1_vdpau atrac3p flic mpeg1video aura flv mpeg2video aura2 fourxm mpeg4 avrn fraps mpeg4_vdpau avrp frwu mpeg_vdpau avs g2m mpeg_xvmc avui g723_1 mpegvideo ayuv g729 mpl2 bethsoftvid gif msa1 bfi gsm msmpeg4v1 msmpeg4v2 qcelp txd msmpeg4v3 qdm2 ulti msrle qdraw utvideo mss1 qpeg v210 mss2 qtrle v210x msvideo1 r10k v308 mszh r210 v408 mts2 ra_144 v410 mvc1 ra_288 vb mvc2 ralf vble mxpeg rawvideo vc1 nellymoser realtext vc1_vdpau nuv rl2 vc1image on2avc roq vcr1 opus roq_dpcm vima paf_audio rpza vmdaudio paf_video rv10 vmdvideo pam rv20 vmnc pbm rv30 vorbis pcm_alaw rv40 vp3 pcm_bluray s302m vp5 pcm_dvd sami vp6 pcm_f32be sanm vp6a pcm_f32le sgi vp6f pcm_f64be sgirle vp7 pcm_f64le shorten vp8 pcm_lxf sipr vp9 pcm_mulaw smackaud vplayer pcm_s16be smacker vqa pcm_s16be_planar smc wavpack pcm_s16le smvjpeg webp pcm_s16le_planar snow webvtt pcm_s24be sol_dpcm wmalossless pcm_s24daud sonic wmapro pcm_s24le sp5x wmav1 pcm_s24le_planar srt wmav2 pcm_s32be ssa wmavoice pcm_s32le subrip wmv1 pcm_s32le_planar subviewer wmv2 pcm_s8 subviewer1 wmv3 pcm_s8_planar sunrast wmv3_vdpau pcm_u16be svq1 wmv3image pcm_u16le svq3 wnv1 pcm_u24be tak ws_snd1 pcm_u24le targa xan_dpcm pcm_u32be targa_y216 xan_wc3 pcm_u32le text xan_wc4 pcm_u8 theora xbin pcm_zork thp xbm pcx tiertexseqvideo xface pgm tiff xl pgmyuv tmv xsub pgssub truehd xwd pictor truemotion1 y41p pjs truemotion2 yop png truespeech yuv4 ppm tscc zero12v prores tscc2 zerocodec prores_lgpl tta zlib ptx twinvq zmbv Enabled encoders: a64multi jpegls ppm a64multi5 libspeex prores aac ljpeg prores_aw ac3 mjpeg prores_ks ac3_fixed movtext qtrle adpcm_adx mp2 r10k adpcm_g722 mp2fixed r210 adpcm_g726 mpeg1video ra_144 adpcm_ima_qt mpeg2video rawvideo adpcm_ima_wav mpeg4 roq adpcm_ms msmpeg4v2 roq_dpcm adpcm_swf msmpeg4v3 rv10 adpcm_yamaha msvideo1 rv20 alac nellymoser s302m alias_pix pam sgi amv pbm snow ass pcm_alaw sonic asv1 pcm_f32be sonic_ls asv2 pcm_f32le srt avrp pcm_f64be ssa avui pcm_f64le subrip ayuv pcm_mulaw sunrast bmp pcm_s16be svq1 cinepak pcm_s16be_planar targa cljr pcm_s16le tiff comfortnoise pcm_s16le_planar tta dca pcm_s24be utvideo dnxhd pcm_s24daud v210 dpx pcm_s24le v308 dvbsub pcm_s24le_planar v408 dvdsub pcm_s32be v410 dvvideo pcm_s32le vorbis eac3 pcm_s32le_planar wavpack ffv1 pcm_s8 webvtt ffvhuff pcm_s8_planar wmav1 flac pcm_u16be wmav2 flashsv pcm_u16le wmv1 flashsv2 pcm_u24be wmv2 flv pcm_u24le xbm g723_1 pcm_u32be xface gif pcm_u32le xsub h261 pcm_u8 xwd h263 pcx y41p h263p pgm yuv4 huffyuv pgmyuv zlib jpeg2000 png zmbv Enabled hwaccels: h263_vaapi mpeg1_xvmc mpeg4_vdpau h263_vdpau mpeg2_vaapi vc1_vaapi h264_vaapi mpeg2_vdpau vc1_vdpau h264_vdpau mpeg2_xvmc wmv3_vaapi mpeg1_vdpau mpeg4_vaapi wmv3_vdpau Enabled parsers: aac dvd_nav mpegvideo aac_latm dvdsub opus ac3 flac png adx gsm pnm bmp h261 rv30 cavsvideo h263 rv40 cook h264 tak dca hevc vc1 dirac mjpeg vorbis dnxhd mlp vp3 dpx mpeg4video vp8 dvbsub mpegaudio vp9 Enabled demuxers: aac h263 nut ac3 h264 nuv act hevc ogg adf hls oma adp hnm paf adx ico pcm_alaw aea idcin pcm_f32be afc idf pcm_f32le aiff iff pcm_f64be amr ilbc pcm_f64le anm image2 pcm_mulaw apc image2_alias_pix pcm_s16be ape image2_brender_pix pcm_s16le aqtitle image2pipe pcm_s24be asf image_bmp_pipe pcm_s24le ass image_dpx_pipe pcm_s32be ast image_exr_pipe pcm_s32le au image_j2k_pipe pcm_s8 avi image_pictor_pipe pcm_u16be avr image_png_pipe pcm_u16le avs image_sgi_pipe pcm_u24be bethsoftvid image_sunrast_pipe pcm_u24le bfi image_tiff_pipe pcm_u32be bink ingenient pcm_u32le bintext ipmovie pcm_u8 bit ircam pjs bmv iss pmp boa iv8 pva brstm ivf pvf c93 jacosub qcp caf jv r3d cavsvideo latm rawvideo cdg live_flv realtext cdxl lmlm4 redspark cine loas rl2 concat lrc rm data lvf roq daud lxf rpl dfa m4v rsd dirac matroska rso dnxhd mgsts rtp dsf microdvd rtsp dsicin mjpeg sami dts mlp sap dtshd mlv sbg dv mm sdp dxa mmf sdr2 ea mov segafilm ea_cdata mp3 shorten eac3 mpc siff epaf mpc8 sln ffm mpegps smacker ffmetadata mpegts smjpeg filmstrip mpegtsraw smush flac mpegvideo sol flic mpl2 sox flv mpsub spdif fourxm msnwc_tcp srt frm mtv str g722 mv subviewer g723_1 mvi subviewer1 g729 mxf swf gif mxg tak gsm nc tedcaptions gxf nistsphere thp h261 nsv tiertexseq tmv voc wsvqa truehd vplayer wtv tta vqf wv tty w64 xa txd wav xbin vc1 wc3 xmv vc1t webm_dash_manifest xwma vivo webvtt yop vmd wsaud yuv4mpegpipe vobsub Enabled muxers: a64 ipod pcm_s24be ac3 ircam pcm_s24le adts ismv pcm_s32be adx ivf pcm_s32le aiff jacosub pcm_s8 amr latm pcm_u16be asf lrc pcm_u16le asf_stream m4v pcm_u24be ass matroska pcm_u24le ast matroska_audio pcm_u32be au md5 pcm_u32le avi microdvd pcm_u8 avm2 mjpeg psp bit mkvtimestamp_v2 rawvideo caf mlp rm cavsvideo mmf roq crc mov rso data mp2 rtp daud mp3 rtsp dirac mp4 sap dnxhd mpeg1system segment dts mpeg1vcd smjpeg dv mpeg1video smoothstreaming eac3 mpeg2dvd sox f4v mpeg2svcd spdif ffm mpeg2video speex ffmetadata mpeg2vob srt filmstrip mpegts stream_segment flac mpjpeg swf flv mxf tee framecrc mxf_d10 tg2 framemd5 null tgp g722 nut truehd g723_1 oga uncodedframecrc gif ogg vc1 gxf oma vc1t h261 opus voc h263 pcm_alaw w64 h264 pcm_f32be wav hds pcm_f32le webm hevc pcm_f64be webm_dash_manifest hls pcm_f64le webvtt ico pcm_mulaw wtv ilbc pcm_s16be wv image2 pcm_s16le yuv4mpegpipe image2pipe Enabled protocols: cache hls rtmpt concat http rtp crypto httpproxy sctp data md5 srtp ffrtmphttp mmsh subfile file mmst tcp ftp pipe udp gopher rtmp unix Enabled filters: aconvert copy nullsink adelay crop nullsrc aecho curves overlay aeval dctdnoiz pad aevalsrc decimate pan afade dejudder perms aformat deshake pixdesctest ainterleave drawbox psnr allpass drawgrid removelogo alphaextract earwax replaygain alphamerge edgedetect rgbtestsrc amerge elbg rotate amix equalizer scale amovie extractplanes select anull fade sendcmd anullsink field separatefields anullsrc fieldmatch setdar apad fieldorder setfield aperms flanger setpts aphaser format setsar aresample fps settb aselect framepack showcqt asendcmd framestep showinfo asetnsamples gradfun showspectrum asetpts haldclut showwaves asetrate haldclutsrc shuffleplanes asettb hflip signalstats ashowinfo highpass silencedetect asplit histogram sine astats hqx smptebars astreamsync hue smptehdbars atempo idet split atrim il swapuv avectorscope interleave telecine bandpass join testsrc bandreject life thumbnail bass lowpass tile bbox lut transpose biquad lut3d treble blackdetect lutrgb trim blend lutyuv unsharp cellauto mandelbrot vflip channelmap mergeplanes vignette channelsplit movie volume color negate volumedetect colorbalance noformat w3fdif colorchannelmixer noise yadif compand null zoompan concat Enabled bsfs: aac_adtstoasc imx_dump_header mp3_header_decompress chomp mjpeg2jpeg noise dump_extradata mjpega_dump_header remove_extradata h264_mp4toannexb mov2textsub text2movsub Enabled indevs: alsa jack oss dv1394 lavfi v4l2 fbdev Enabled outdevs: alsa oss v4l2 fbdev sdl xv License: LGPL version 2.1 or later Creating config.mak, config.h, and doc/config.texi... WARNING: pkg-config not found, library detection may fail.
follow-up: 11 comment:10 by , 10 years ago
Replying to cehoyos:
I am willing to take the burden.
I do not think it can work that way for the build system. The extra code complexity is a nuisance for anyone who needs to look at it, and, unlike for an isolated decoder or demuxer, that means potentially any contributor. The slowness, of course, affects everyone.
Removing this support means introducing a regression.
The difference between a regression and the cleanup of an obsolete feature become useless is only a matter of point of view.
Not everyone who wants to compile FFmpeg can install on the target system.
Is there a misunderstanding here? pkg-config is required on the build system, never on the target system.
You misunderstand: When I test, I never install the libraries but always link them from the build directory. (The basis is just my workflow for testing FFmpeg because of user reports that include using external libraries.)
For the sake of clarity, I suggest we keep the discussion about your use case separate from the discussion about generic users.
Concerning generic users, can you quote actual situations where pkg-config is impossible to install, or at least significantly harder than the other required build components (including yasm)?
You certainly will need to invoke exotic cases, cross-building or such, but please keep it realistic.
Concerning your personal use case, I am pretty sure that it is possible to alter your work flow just slightly to adjust to a configure that requires pkg-config. You may possibly even save time by doing that.
If I understand you correctly, you need to be able to build ffmpeg with libfoo that you just built in a separate directory but not installed. That looks pretty easy to achieve. Do you have any other requirement?
follow-up: 12 comment:11 by , 10 years ago
Replying to Cigaes:
Replying to cehoyos:
I am willing to take the burden.
I do not think it can work that way for the build system.
I don't understand: Why should something that does work fine for x264 not work for other libraries?
The extra code complexity is a nuisance for anyone who needs to look at it, and, unlike for an isolated decoder or demuxer, that means potentially any contributor.
I very much doubt this, especially when comparing the "complexity" of our configure script with any other part of FFmpeg.
The slowness, of course, affects everyone.
Could you elaborate?
Removing this support means introducing a regression.
The difference between a regression and the cleanup of an obsolete feature become useless is only a matter of point of view.
Of course.
I opened this ticket because I consider this issue a (severe) regression.
Not everyone who wants to compile FFmpeg can install on the target system.
Is there a misunderstanding here? pkg-config is required on the build system, never on the target system.
I meant the build system, sorry for the wrong wording.
You misunderstand: When I test, I never install the libraries but always link them from the build directory. (The basis is just my workflow for testing FFmpeg because of user reports that include using external libraries.)
For the sake of clarity, I suggest we keep the discussion about your use case separate from the discussion about generic users.
I do consider myself a user.
Concerning generic users, can you quote actual situations where pkg-config is impossible to install, or at least significantly harder than the other required build components (including yasm)?
I mean every user who is not an admin on the build system. Note that yasm is not needed on all targets.
You certainly will need to invoke exotic cases, cross-building or such, but please keep it realistic.
Please understand while for you (as for many other FFmpeg developers) it is completely clear how to use pkg-config, for me as for many users who post on the user mailing list it is needlessly difficult.
Concerning your personal use case, I am pretty sure that it is possible to alter your work flow just slightly to adjust to a configure that requires pkg-config. You may possibly even save time by doing that.
I would prefer to continue being able to configure FFmpeg without using pkg-config.
If I understand you correctly, you need to be able to build ffmpeg with libfoo that you just built in a separate directory but not installed. That looks pretty easy to achieve. Do you have any other requirement?
Yes, I just want to be able to build (configure and build) FFmpeg with (most) external libraries without having to use pkg-config.
follow-ups: 13 14 comment:12 by , 10 years ago
Replying to cehoyos:
I don't understand: Why should something that does work fine for x264 not work for other libraries?
I want to get rid of it for x264 too! But for x264, it is already there, for speex, it has been removed, and I object it coming back.
Could you elaborate?
configure takes a lot of time, blocking for the rest of the build process.
Of course.
I opened this ticket because I consider this issue a (severe) regression.
And I consider it good riddance: configure is faster, simpler, more readable, more reliable.
I meant the build system, sorry for the wrong wording.
Then of course they can install something on the build system: they are installing ffmpeg.
I mean every user who is not an admin on the build system. Note that yasm is not needed on all targets.
Actual practical examples, please.
Please understand while for you (as for many other FFmpeg developers) it is completely clear how to use pkg-config, for me as for many users who post on the user mailing list it is needlessly difficult.
sudo apt-get install pkg-config
There is nothing more to do in normal cases. In non-normal cases, the user already did something way more complex than export PKG_CONFIG_PATH=/some/path.
Yes, I just want to be able to build (configure and build) FFmpeg with (most) external libraries without having to use pkg-config.
“without having to use pkg-config” is not a functional need.
comment:13 by , 10 years ago
Replying to Cigaes:
Replying to cehoyos:
I don't understand: Why should something that does work fine for x264 not work for other libraries?
I want to get rid of it for x264 too! But for x264, it is already there, for speex, it has been removed, and I object it coming back.
The patch was not reviewed and since libspeex is not completely outdated, we should really allow installation without jumping through the pkg-config hole.
Could you elaborate?
configure takes a lot of time, blocking for the rest of the build process.
Could you elaborate how the patch made configure faster or how the workaround would make it slower?
Of course.
I opened this ticket because I consider this issue a (severe) regression.
And I consider it good riddance: configure is faster, simpler, more readable, more reliable.
I don't think it is faster and calling removing a feature being more reliable is hard to understand for me.
I meant the build system, sorry for the wrong wording.
Then of course they can install something on the build system: they are installing ffmpeg.
I never install FFmpeg.
I mean every user who is not an admin on the build system. Note that yasm is not needed on all targets.
Actual practical examples, please.
yasm is not needed on arm and powerpc.
Please understand while for you (as for many other FFmpeg developers) it is completely clear how to use pkg-config, for me as for many users who post on the user mailing list it is needlessly difficult.
sudo apt-get install pkg-config
This does not even work on my development system and it certainly doesn't work for people using servers where they are not admins.
But I meant using pkg-config not installing it.
There is nothing more to do in normal cases. In non-normal cases, the user already did something way more complex than
export PKG_CONFIG_PATH=/some/path.
I consider this at least a magnitude more difficult than setting a path.
Yes, I just want to be able to build (configure and build) FFmpeg with (most) external libraries without having to use pkg-config.
“without having to use pkg-config” is not a functional need.
It is needed for my workflow and was very often requested by users on the user mailing list.
follow-up: 15 comment:14 by , 10 years ago
Replying to Cigaes:
Replying to cehoyos:
Could you elaborate?
configure takes a lot of time, blocking for the rest of the build process.
how much time is saved by removing non pkg-config cases ?
I mean every user who is not an admin on the build system. Note that yasm is not needed on all targets.
Actual practical examples, please.
Can you or someone else document on the wiki how to setup & use pkg config for the various cases that people need ?
One case iam aware of is cross building, or maybe configure could be made to just work in that case without installing wraper scripts or whatever
comment:15 by , 10 years ago
Replying to michael:
how much time is saved by removing non pkg-config cases ?
I must admit, I got carried away. Thinking more specifically about it, the non pkg-config case will only take time if the library was enabled but pkg-config fails. It will only be a burden when auto-detection will be implemented.
Can you or someone else document on the wiki how to setup & use pkg config for the various cases that people need ?
Sure. Patch on the mailing-list.
One case iam aware of is cross building, or maybe configure could be made to just work in that case without installing wraper scripts or whatever
The most common cases can probably be automated, but I am not familiar enough with cross-compiling to know what the most common cases are. If we can get the linker's search path (ld --verbose | grep SEARCH_DIR), we can set PKG_CONFIG_LIBDIR accordingly, but I do not know if that default search path is usually relevant.
comment:16 by , 9 years ago
| Cc: | added |
|---|
@cehoyos: is this still an issue? Above patch has been merged,
so pkg-config usage should hopefully be clear.
I am going to reduce priority of this bug in next few days since usage of pkg-config has been clarified; raise objections if you have any.
comment:17 by , 9 years ago
The patch fixing this regression can be found on the development mailing list:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/187278
comment:18 by , 9 years ago
Yes, what I meant was the documentation update on usage of pkg-config has been merged as commit 40948819fcfe5bba39531df358dc50d52cee10d4.
My point is that pkg-config usage has been clarified, so therefore this ticket does not deserve an "important" priority. This simply distracts from other arguably more pressing issues on the bug tracker. By no means am I saying to close this ticket, but to degrade it to "normal" or ideally "minor" (in my view).
follow-up: 21 comment:19 by , 9 years ago
I can hardly see a more pressing issue than a user-reported regression.
comment:20 by , 9 years ago
Even among user-reported regressions, some are arguably more severe than others and this is a subjective matter, e.g most users feel that their own tickets are more "important". Anyway, I digress.
I am interested in resolving this issue, and it seems like it has been stuck for a while with no consensus among the devs. Thoughts on how to proceed? Is it worthwhile resurrecting the old thread on this?
follow-up: 22 comment:21 by , 9 years ago
Replying to cehoyos:
I can hardly see a more pressing issue than a user-reported regression.
Its not a regression if the change was intentional and the old way is now unsupported.
This ticket should be closed, it was clearly quite intentional that pkg-config is now required, and we have proper documentation in place on how to set it up as well.
In fact, there isn't even a single user complaining about a regression in this ticket at all.
follow-up: 23 comment:22 by , 9 years ago
Replying to heleppkes:
Replying to cehoyos:
I can hardly see a more pressing issue than a user-reported regression.
Its not a regression if the change was intentional and the old way is now unsupported.
This ticket should be closed, it was clearly quite intentional that pkg-config is now required, and we have proper documentation in place on how to set it up as well.
I really wonder what "intentional" means for a change that was not discussed on any FFmpeg mailiing list.
In fact, there isn't even a single user complaining about a regression in this ticket at all.
I did not claim that a user opened a ticket but I don't consider bug reports on the user mailing list less helpful.
follow-up: 24 comment:23 by , 9 years ago
Replying to cehoyos:
Replying to heleppkes:
Replying to cehoyos:
I can hardly see a more pressing issue than a user-reported regression.
Its not a regression if the change was intentional and the old way is now unsupported.
This ticket should be closed, it was clearly quite intentional that pkg-config is now required, and we have proper documentation in place on how to set it up as well.
I really wonder what "intentional" means for a change that was not discussed on any FFmpeg mailiing list.
Ok, so I have opened a thread on the mailing list for people to discuss this:
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176485.html
In fact, there isn't even a single user complaining about a regression in this ticket at all.
I did not claim that a user opened a ticket but I don't consider bug reports on the user mailing list less helpful.
follow-up: 25 comment:24 by , 9 years ago
Replying to gajjanag:
Replying to cehoyos:
Replying to heleppkes:
Replying to cehoyos:
I can hardly see a more pressing issue than a user-reported regression.
Its not a regression if the change was intentional and the old way is now unsupported.
This ticket should be closed, it was clearly quite intentional that pkg-config is now required, and we have proper documentation in place on how to set it up as well.
I really wonder what "intentional" means for a change that was not discussed on any FFmpeg mailiing list.
Ok, so I have opened a thread on the mailing list for people to discuss this:
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176485.html
I see no response to the thread I opened. As such, to me it looks like no one is interested in discussing this, and the change was thus "intentional". Unless someone responds to that thread soon, this ticket should be closed. I will leave it open for a few more days, and in absence of a response will close the ticket.
@cehoyos: you can (and perhaps will) reopen this ticket. Nevertheless, I consider the above closure symbolic, since to me (and perhaps many others) the above represents a clean closure, since we provided an opportunity that was not taken to discuss this.
In fact, there isn't even a single user complaining about a regression in this ticket at all.
I did not claim that a user opened a ticket but I don't consider bug reports on the user mailing list less helpful.
comment:25 by , 9 years ago
Replying to gajjanag:
Ok, so I have opened a thread on the mailing list for people to discuss this:
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176485.html
I see no response to the thread I opened. As such, to me it looks like no one is interested in discussing this, and the change was thus "intentional". Unless someone responds to that thread soon, this ticket should be closed. I will leave it open for a few more days, and in absence of a response will close the ticket.
Why should the users that have reported the issue react on the development mailing list?
Why do we (suddenly!) refuse to fix regressions?
Why should we handle libspeex different from other external libraries like x264?
It is very easy to fix this ticket, I am strongly opposed to closing it just because not all developers use systems without pkg-config or want to force everybody to use it.
comment:26 by , 9 years ago
I am strongly opposed to closing it
OK. I'm strongly opposed to complicating the configure script by supporting non-pkg-config detection.
follow-up: 28 comment:27 by , 9 years ago
@cehoyos: you rightly point out the inconsistency.
I think what we need to do is make FFmpeg take a clear stance on this issue among some options:
- We support pkg-config: in this case, we support it all the way, and add all required configure checks. I think very few people like this. I certainly don't.
- We don't support pkg-config: in this case we remove all pkg-config checks, and add relevant documentation in visible places saying that pkg-config is a build dependency. I personally don't mind this. However, I vaguely recall some legitimate reasons for supporting builds without pkg-config.
- We support pkg-config with some libraries and not with others: I consider this the most half baked option, but that is what we have currently. In this case, documentation must be in place for describing which external libs can be used without pkg-config, and which ones can't. This is annoying.
BTW, in order to call it a regression, there should be proof that FFmpeg did support building without pkg-config at one point - I am not counting behavior in practice, but documentation. FFmpeg clearly delineates build platforms, I see no reason for why build tools (e.g pkg-config) should be different.
In the absence of such proof, one can't call this a regression in my view. Otherwise, theoretically any change in undocumented behavior/state modifications can be called a "regression".
follow-up: 29 comment:28 by , 9 years ago
Replying to gajjanag:
@cehoyos: you rightly point out the inconsistency.
I think what we need to do is make FFmpeg take a clear stance on this issue among some options:
- We support pkg-config: in this case, we support it all the way, and add all required configure checks. I think very few people like this. I certainly don't.
- We don't support pkg-config: in this case we remove all pkg-config checks, and add relevant documentation in visible places saying that pkg-config is a build dependency. I personally don't mind this. However, I vaguely recall some legitimate reasons for supporting builds without pkg-config.
- We support pkg-config with some libraries and not with others: I consider this the most half baked option, but that is what we have currently. In this case, documentation must be in place for describing which external libs can be used without pkg-config, and which ones can't. This is annoying.
We already agreed on having pkg-config as default and detection without pkg-config as fallback.
BTW, in order to call it a regression, there should be proof that FFmpeg did support building without pkg-config at one point - I am not counting behavior in practice, but documentation. FFmpeg clearly delineates build platforms, I see no reason for why build tools (e.g pkg-config) should be different.
In the absence of such proof, one can't call this a regression in my view. Otherwise, theoretically any change in undocumented behavior/state modifications can be called a "regression".
A feature that breaks default detection of a library at least on aix, android, mingw and osx without any discussion or documentation is certainly a regression that cannot be fixed by an entry in the wiki (or the Changelog). But as said, this is trivial to fix, there should be no further discussion needed.
comment:29 by , 9 years ago
Replying to cehoyos:
Replying to gajjanag:
@cehoyos: you rightly point out the inconsistency.
I think what we need to do is make FFmpeg take a clear stance on this issue among some options:
- We support pkg-config: in this case, we support it all the way, and add all required configure checks. I think very few people like this. I certainly don't.
- We don't support pkg-config: in this case we remove all pkg-config checks, and add relevant documentation in visible places saying that pkg-config is a build dependency. I personally don't mind this. However, I vaguely recall some legitimate reasons for supporting builds without pkg-config.
- We support pkg-config with some libraries and not with others: I consider this the most half baked option, but that is what we have currently. In this case, documentation must be in place for describing which external libs can be used without pkg-config, and which ones can't. This is annoying.
We already agreed on having pkg-config as default and detection without pkg-config as fallback.
Did not know that. It certainly does not feel that way since many developers are still not happy about this, and comments here and on the mailing list reflect a lack of agreement about this.
I will give you the benefit of doubt on this one, and apologize for my negative attitude about this ticket.
BTW, in order to call it a regression, there should be proof that FFmpeg did support building without pkg-config at one point - I am not counting behavior in practice, but documentation. FFmpeg clearly delineates build platforms, I see no reason for why build tools (e.g pkg-config) should be different.
In the absence of such proof, one can't call this a regression in my view. Otherwise, theoretically any change in undocumented behavior/state modifications can be called a "regression".
A feature that breaks default detection of a library at least on aix, android, mingw and osx without any discussion or documentation is certainly a regression that cannot be fixed by an entry in the wiki (or the Changelog). But as said, this is trivial to fix, there should be no further discussion needed.
Note: no user without pkg-config complained about this AFAIK