Bugzilla Bug 82915

There are a lot of problems with the qemacs ebuild, some the result of
upstream and some due to the ebuild.  The list I've personally fallen foul
of is:

* qemacs doesn't install headers, which makes building plugins nigh on
  impossible.  Unless of course you want to ship headers with all your
  plugins, or require the tarball for a simple user plugin build :/
* The package enforces some CFLAGS on x86.
* There is a name clash with app-editors/qe over binary name, they also
  share a data directory.  Although neither of the packages try to
  install files with the same name in the datadir, or read files from the
  other package's contents [in their current versions].
* The ebuild doesn't support the use of ffmpeg, a surprisingly cool
  feature for a text editor.  Build it and fire up an mpeg!
* The build will fail, if like me, you don't have a version of X
  compiled with xvideo support for whatever strange reason.

  The attached patches fix all of these bugs, I know I could have perhaps
split the bugs up a little but I decided against it a few minutes ago(flames
accepted).  The reason being the changes are that massive compared to the
old ebuild after filing ~6 bugs the files wouldn't really have been all that
recognisable anyway(and the fixes should be quite obvious).  If you believe
they should have been split, or would prefer them split for some reason or
another then leave a comment saying so.

  There was also a secondary reason, and that is one of testing.  I've been
running this ebuild at home and on work machines for a little while now(short
of the cleanup this morning).  Which means it has had testing in its current 
state, and definitely an amount of testing I've not got the time to give it if
it was split.

  qemacs-0.3.1-Makefile-gentoo.patch:
* Removes the forced CFLAGS.
* Makes sure install directories are built.
* Installs the binary as qemacs.
* Installs csstoqe, the tool which generates usable plugin source
  from CSS files(see below for an example).
* Changes the install system to use DESTDIR, that many lines were
  being touched it was zero cost.
* Changes the include location referenced in the plugin-example
  Makefile, so it usable as template after the package is installed.
* Installs the ffplay symlink as qemacs-ffplay, because when ffmpeg is
  installed it already contains a ffplay executable.
  qemacs-0.3.1-manpage-ref-fix.patch:
  * No brainer. Cosmetic fix for the manpage so it references the new,
  non-clashing, binary name.
  qemacs-0.3.1-qemacs-datadir.patch:
  * Changes to use /usr/{lib,share}/qemacs and ~/.qemacs instead of
  just using qe.  As as I said above right now there aren't any
  clashes I'm aware of for data/config files, but surely it is
  better to make users aware now instead of waiting until it breaks.
  qemacs-0.3.1-use-installed-ffmpeg.patch:
  * When ffmpeg is set in USE use the installed version of ffmpeg and
  dynamically link, instead of requiring the source tree and
  statically linking the two packages.  It changes the configure
  script, source files and Makefile.
  qemacs-0.3.1-r1-fixup.patch:
* Added support for xv USE flag, like I noted above builds will fail
  without this on boxes where xv is unset.
* Added support for ffmpeg USE flag, and appropriate mode.  I'm
  little surprised this hasn't been added earlier, it has to be one
  of the coolest features I've ever seen in an editor.
* Applies all the patches, with perhaps too much commentary if such
  a thing is possible.
* A little cosmetic fix to the man page, so it shows the real
  location of the README file.
* Minor cleanup to use use_enable instead of ugly old myconf.
* Specifies a noop for src_test, as it will fail with maketest set
  in FEATURES due to apparent craziness in the build system ;)
* Installs the example configuration file, because well it should be
  installed.
* Installs the plugin example, and headers needed to compile
  plugins.
* Displays a big fat message telling users about the changes.

  As some kind of weak enticement for the mighty devs to jump on the case
and let me build plugins from a default qemacs build I've decided to knock
up a 5 minute hack of a Gentoo Guide WYSIWYG mode to show you what you could
be missing with the current ebuild.  It uses not only the includes which are
now available, but also the csstoqe binary as an example of why they should
be installed ;)  Granted it hasn't been tested much, because I have never
actually used the Guide format for anything.  However should anyone find it
interesting, I would be willing to clean/fix/complete it.  You can find it
at http://www.jnrowe.ukfsn.org/files/qemacs-gguide.tar.bz2, as I didn't
think it was really appropriate to attach here.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Created an attachment (id=51850) [details]
qemacs-0.3.1-Makefile-gentoo.patch

Created an attachment (id=51851) [details]
qemacs-0.3.1-manpage-ref-fix.patch

Created an attachment (id=51852) [details]
qemacs-0.3.1-qemacs-datadir.patch

Created an attachment (id=51853) [details]
qemacs-0.3.1-use-installed-ffmpeg.patch

Created an attachment (id=51854) [details]
qemacs-0.3.1-r1-fixup.patch

diff against qemacs-0.3.1-r1.ebuild

Thanks for the improvements. All patches look fine to me,
but I'd like to ask you ffmpeg patch. I think it should be
applied unconditionally (because it can be disabled by econf,
so there is no point to not apply it in src_unpack). Also,
if I turn on ffmpeg support, qemacs won't compile with 
ffmpeg-0.4.9_pre1 (while it does compile with ffmpeg-0.4.{7,8}).
I didn't look into the difference between 0.4.9_pre1 and
other versions, but DEPEND="ffmpeg? ( media-video/ffmpeg )" 
should reflect it.

I agree there is no reason that the patch shouldn't be applied regardless of 
the ffmpeg USE flag.  I think really it just comes down to a matter of habit 
for me :/

I wasn't really aware of the _pre version of ffmpeg, so obviously I hadn't 
tested it.  I will take a look at it sometime on Friday/Saturday though.  I'd 
prefer to see a fix for newer ffmpeg versions(if they are all going to break 
not just a flaw in the pre-release), than failure if/when ffmpeg 0.4.9 hits 
stable.

And yeah, I will take a note of ~ARCH versions of depends when filing bugs in
future ;)

Regardless of the outcome I will freshen up the attachments over the weekend
to take in to account your comments.

Well, after poking around a bit it appears that nearly every release of ffmpeg 
breaks compatibility with previous versions :(  It also appears, from the 
packages I checked, that most packages that require ffmpeg ship with a specific
version of it(I would imagine due to compatibility problems)

For these reasons, I'm tempted to come to conclusion it would that either:
  1) Pull in a specific version and link statically if ffmpeg is set(like the
packages wants to do without the patch).  Obvious problems being either the
ebuild becomes enormous to pull in all the config for ffmpeg and will probably
never take fixes from the ffmpeg build due to time, or the ffmpeg is not 
configurable at all.
  2) Don't support ffmpeg. I don't really like the idea, although where it 
matters for me at work I'm already pushing ffmpeg support as a plugin anyway :/

I would appreciate any comments on the matter, obviously I'm holding off on 
other updates until a conclusion of some kind is reached.

  This is a fixed and updated version of the original ebuild, which had a few 
prolems:

        -- docdir sed changed to PVR, as it should've been.
        -- warning now read "prior to 0.3.1-r2" as it should have been updated with
           the -r1 release(the result of sitting on this since November :/ ).
        -- plugin-example file were being installed in to the wrong directory due 
           to clogged brain. Fixed.

  FFMPEG support has been dropped for the time being, until some kind of 
resolution is made.  If/when this bug is closed like this I will open another,
as I should've originally, with the ffmpeg stuff.

(From update of attachment 51853 [details])
No longer applicable in current state.

Created an attachment (id=52957) [details]
qemacs-0.3.1-r2-fixup.patch

Thanks. I applied these patches except ffmpeg one.
The reason why I didn't commit is that qemacs won't run
if I compile it with gcc-3.4. (It compiles fine but
segfaults) I thought this was related to these patches
but even 0.3.1-r1 and 0.3.1 fail to start if I build
them with gcc-3.4, I came to think it's okay to add
the patches. 

Can you compile and run qemacs with gcc-3.4? I guess
you never tried because you didn't have gcc-3.4 patch
in your ebuild. If you have any idea about this issue
I'd appreciate your help.

  Honestly, I don't really try unstable toolchain items at all.  I like to
limit myself to unstable items that can't cause strange breakages ;)  I will
have a look at it though.

  And thanks for the nudge on ffmpeg too, I had completely forgotten about 
that.