Created attachment 293943 [details] lyx-2.0.1 (edited ebuild) With an effort, I can emerge lyx-2.0 on ~x86-macos. So, I'd like to share it on the prefix tree. These packages are DEPENDs of lyx simply ecopyable: app-text/noweb dev-tex/dvipost I used a patch to configure and some edit on ebuild. See the attachments.
Created attachment 293945 [details, diff] lyx-2.0.1-macosx.patch patch against configure
@tex: app-text/noweb needs ED in src_install, so an EAPI-bump to 3. Is that ok with you if we do that to a revision bump? @tex/aballier: Just to ack, the lyx configure patch (will be transformed in a .ac+ patch) is ok with you?
(In reply to comment #2) > Is that ok with you if we do that to a revision bump? To elaborate on this, only if you think this is necessary. I'd prefer not to bump since the change would be straightforward.
is there reason why not push your patch upstream instead of patching this only in gentoo? (the change needs to be done primarily at configure.ac)?
(In reply to comment #4) > is there reason why not push your patch upstream instead of patching this only > in gentoo? (the change needs to be done primarily at configure.ac)? Basically, there is no obstacle, but, you know, reporting to upstream is just one heavy step further.
Created attachment 295005 [details, diff] lyx-2.0.1-lyxinclude.m4-macosx.patch A direct patch is not a good way to change configure. This time, the patch is applied to one of its source, config/lyxinclude.m4.
Created attachment 295007 [details] lyx-2.0.2 (edited ebuild) There appears app-office/lyx-2.0.2, thus I also update the ebuild of this bug. Changes: 1. patch for configure is changed as above, and it makes us introduce eautoconf. 2. X-related packages are conditioned X? in COMMONDEPEND, since Qt on OS X does not depend on X.
i don't think this is the right direction. we shouldn't keep specific patchsets unless they are just gentoo specific.
I reported to upstream, too: http://www.lyx.org/trac/ticket/7927
(In reply to comment #8) > i don't think this is the right direction. > we shouldn't keep specific patchsets unless they are just gentoo specific. Do you imagine a patch is always instantly accepted by upstream?
> I reported to upstream, too: thanks. >Do you imagine a patch is always instantly accepted by upstream? :) not always and not instantly. however pretty good chances to get review from competent people here.
will be part of upstream 2.0.3
(In reply to comment #12) > will be part of upstream 2.0.3 its now in tree, so prefix team can go ahead and test it
Created attachment 304737 [details] lyx-2.0.3 (edited ebuild) Changes from the previous: 1. thanks to the upstream, no OS X specific patch is applied 2. it uses ldflags-append instead of direct substitution to LDFLAGS (3. changes in original ebuild from that of 2.0.2)
please can you comment on the changed line: - python_convert_shebangs -r 2 "${D}"/usr/share/${PN} + python_convert_shebangs -r 2 "${ED}"/usr/share/${PN} (i quickly looked in Gentoo Development Guide and found no entry for "E") otherwise looks good.
(In reply to comment #15) > please can you comment on the changed line: > - python_convert_shebangs -r 2 "${D}"/usr/share/${PN} > + python_convert_shebangs -r 2 "${ED}"/usr/share/${PN} > > (i quickly looked in Gentoo Development Guide and found no entry for "E") > > otherwise looks good. ED is EPREFIXed D. See Prefix Tech Doc: http://www.gentoo.org/proj/en/gentoo-alt/prefix/techdocs.xml EAPI 3: http://devmanual.gentoo.org/ebuild-writing/eapi/index.html
Aha, thanks. Alexis, I'm fine with adding this to portage (should it be -r1? the changes look harmless...)
(In reply to comment #17) > Aha, thanks. Alexis, I'm fine with adding this to portage (should it be -r1? > the changes look harmless...) no it should not be -r1, but for me its not harmless: - please attach diffs to gentoo-x86 ebuilds, its easier to review now on the diff side: - x11-libs/libXrandr - x11-libs/libXcursor - x11-libs/libXrender - x11-libs/libXfixes - x11-libs/libXext - x11-libs/libSM - x11-libs/libICE - x11-libs/libX11 - x11-libs/libXau - x11-libs/libXdmcp + X? ( + x11-libs/libXrandr + x11-libs/libXcursor + x11-libs/libXrender + x11-libs/libXfixes + x11-libs/libXext + x11-libs/libSM + x11-libs/libICE + x11-libs/libX11 + x11-libs/libXau + x11-libs/libXdmcp + ) where's that X useflag declared and used ? does lyx use these or is it just qt ? (in the latter case, we can drop the dep) - dev-tex/latex2rtf - app-text/unrtf - dev-tex/html2latex - ) + dev-tex/latex2rtf + app-text/unrtf + dev-tex/html2latex + ) unrelated change + if [[ ${CHOST} == *-darwin* ]]; then + append-ldflags "-framework Carbon -framework ApplicationServices -framework AppKit -framework Foundation" + fi + cant this be made at configure / makefile level ? vlc has been doing this for ages for example and i find that kind of special case in an ebuild ugly :) @@ -121,7 +127,8 @@ $(use_with hunspell) \ $(use_with aspell) \ $(use_with enchant) \ - --without-included-boost --disable-stdlib-debug + --without-included-boost --disable-stdlib-debug \ + --with-packaging=posix } probably ok @@ -148,7 +155,7 @@ # fonts needed for proper math display, see also bug #15629 font_src_install - python_convert_shebangs -r 2 "${D}"/usr/share/${PN} + python_convert_shebangs -r 2 "${ED}"/usr/share/${PN} if use hunspell ; then dosym /usr/share/myspell /usr/share/lyx/dicts ok
(In reply to comment #18) > now on the diff side: > > - x11-libs/libXrandr > - x11-libs/libXcursor > - x11-libs/libXrender > - x11-libs/libXfixes > - x11-libs/libXext > - x11-libs/libSM > - x11-libs/libICE > - x11-libs/libX11 > - x11-libs/libXau > - x11-libs/libXdmcp > + X? ( > + x11-libs/libXrandr > + x11-libs/libXcursor > + x11-libs/libXrender > + x11-libs/libXfixes > + x11-libs/libXext > + x11-libs/libSM > + x11-libs/libICE > + x11-libs/libX11 > + x11-libs/libXau > + x11-libs/libXdmcp > + ) > > where's that X useflag declared and used ? > does lyx use these or is it just qt ? (in the latter case, we can drop the > dep) IIRC I took those from ldd lyx binary, so my interpretation was, that we directly need it. Mac reportedly doesn't use X, but some other libs are needed? > @@ -121,7 +127,8 @@ > $(use_with hunspell) \ > $(use_with aspell) \ > $(use_with enchant) \ > - --without-included-boost --disable-stdlib-debug > + --without-included-boost --disable-stdlib-debug \ > + --with-packaging=posix > } > > probably ok at least on linux side of the pond posix is taken by default. i guess this was needed since mac envi chooses macos packaging...
I think the role of X related libraries is played by frameworks on OS X. So let's talk about the last glitch. > + if [[ ${CHOST} == *-darwin* ]]; then > + append-ldflags "-framework Carbon -framework ApplicationServices > -framework AppKit -framework Foundation" > + fi > + > > cant this be made at configure / makefile level ? vlc has been doing this > for ages for example and i find that kind of special case in an ebuild ugly > :) I have tried to pass this via configure before, but haven't succeeded. It means that if you don't like this approach, you have to write and send a patch to upstream. It should be remarked that upstream expects LyX be built as an app on OS X, that is very different way to install a software than traditional unix. On the other hand, Gentoo Prefix tries to mimic linux installation on every platform as far as possible. The discrepancy has to be absorbed in somewhere, and just only one conditional clause is a good compromise, I suppose.
(In reply to comment #19) > (In reply to comment #18) > > now on the diff side: > > > > - x11-libs/libXrandr > > - x11-libs/libXcursor > > - x11-libs/libXrender > > - x11-libs/libXfixes > > - x11-libs/libXext > > - x11-libs/libSM > > - x11-libs/libICE > > - x11-libs/libX11 > > - x11-libs/libXau > > - x11-libs/libXdmcp > > + X? ( > > + x11-libs/libXrandr > > + x11-libs/libXcursor > > + x11-libs/libXrender > > + x11-libs/libXfixes > > + x11-libs/libXext > > + x11-libs/libSM > > + x11-libs/libICE > > + x11-libs/libX11 > > + x11-libs/libXau > > + x11-libs/libXdmcp > > + ) > > > > where's that X useflag declared and used ? > > does lyx use these or is it just qt ? (in the latter case, we can drop the > > dep) > > IIRC I took those from ldd lyx binary, so my interpretation was, that we > directly need it. Mac reportedly doesn't use X, but some other libs are > needed? hmm you shouldnt trust ldd for this :) it displays what libs will be loaded when running lyx, not what lyx itself actually needs for example, if qt needs X on your system then it will display those X libs, however on macos things might be very different. better check the build system for what is really needed and what not to get the deps optimal
(In reply to comment #20) > > + if [[ ${CHOST} == *-darwin* ]]; then > > + append-ldflags "-framework Carbon -framework ApplicationServices > > -framework AppKit -framework Foundation" > > + fi > > + > > > > cant this be made at configure / makefile level ? vlc has been doing this > > for ages for example and i find that kind of special case in an ebuild ugly > > :) > > I have tried to pass this via configure before, but haven't succeeded. > It means that if you don't like this approach, you have to write and send a > patch to upstream. please do send such a patch, i have no knowledge of macos, the only thing i know is that if you need to do this hack, this means lyx will not build out of the box, so it ought to be fixed rather that adding workarounds that will stay forever.
(In reply to comment #22) > please do send such a patch, i have no knowledge of macos, the only thing i > know is that if you need to do this hack, this means lyx will not build out > of the box, so it ought to be fixed rather that adding workarounds that will > stay forever. on the other hand, having a look at INSTALL.MacOSX is pretty instructive: (d) When working without pkgconfig or pkgconfig fails to detect Carbon and Appkit frameworks Current pkgconfig from macports is able to detect the frameworks Qt4 is using. The build of LyX succeeds because the frameworks are added automatically to the linker options. If you need to add them yourself because of link errors, e. g. lyx Undefined symbols: "_FSPathMakeRef"... you have to verify the required frameworks with otool and add them to the LDFLAGS. [...] Currently there are two different Qt4 builds available for download: * with Tiger support it's with Carbon. You have to add export LDFLAGS="$LDFLAGS -framework ApplicationServices -framework Carbon -framework AppKit" * with Cocoa framework without Tiger support you have to add export LDFLAGS="$LDFLAGS -framework ApplicationServices -framework Cocoa -framework AppKit" so it seems the culprit is qt, right ?
(In reply to comment #21) > > IIRC I took those from ldd lyx binary, so my interpretation was, that we > > directly need it. Mac reportedly doesn't use X, but some other libs are > > needed? > > hmm you shouldnt trust ldd for this :) it displays what libs will be loaded > when running lyx, not what lyx itself actually needs > for example, if qt needs X on your system then it will display those X libs, > however on macos things might be very different. > > better check the build system for what is really needed and what not to get > the deps optimal i just went through all libs in "X?" none of them is pulled by lyx directly - its mainly business of Qt deps... so we can get rid of those libX altogether at the end.
My apology, the LDFLAGS hack has not been necessary for the current version. I don't know what brought this change: lyx itself, Qt related ebuilds / eclasses or something.
can you please attach the final diff of the ebuild which work for you? (X deps can be dropped as well as discussed above)
Created attachment 305885 [details] ebuild diff
Alexis, I think this is fine to go in.
patch applied, without whitespace changes and keywords, I'll let the prefix team add their keywords as they like
Thanks all for the work! Keyworded at last!
