Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 47469 - qtcsharp-0.7.1.ebuild (New Package)
Summary: qtcsharp-0.7.1.ebuild (New Package)
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: dotnet
URL:
Whiteboard:
Keywords: EBUILD
: 42180 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-04-10 18:08 UTC by Martin Honermeyer
Modified: 2006-09-25 09:11 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
qtcsharp-0.7.1.ebuild (qtcsharp-0.7.1.ebuild,676 bytes, text/plain)
2004-04-10 18:10 UTC, Martin Honermeyer
Details
qtsharp-0.7.1 ebuild (qtsharp-0.7.1.ebuild,632 bytes, text/plain)
2004-04-13 15:56 UTC, Martin Honermeyer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Honermeyer 2004-04-10 18:08:59 UTC
Hi!


Qt# is a binding of the Qt toolkit to the C# programming language. Have a look at http://qtcsharp.sourceforge.net/. 

The attached ebuild installs the required shared library and CIL DLL. It requires a recent GCC, Qt >=3.1 and Mono >=0.30.

I suggest dev-dotnet/qtcsharp. It works fine for me (on x86).


Best Wishes,
Martin
Comment 1 Martin Honermeyer 2004-04-10 18:10:43 UTC
Created attachment 29054 [details]
qtcsharp-0.7.1.ebuild
Comment 2 Martin Honermeyer 2004-04-13 15:54:50 UTC
There was an issue with the name of the ebuild! It has to be called "qtsharp" which seems to be the right name of the project. 

I am posting the new ebuild. I also corrected the SRC_URI line in order to contain all sourceforge mirrors (via "mirror://"). Didn't know that! Sorry, I am a beginner ;)
Comment 3 Martin Honermeyer 2004-04-13 15:56:29 UTC
Created attachment 29232 [details]
qtsharp-0.7.1 ebuild
Comment 4 Rainer Größlinger (RETIRED) gentoo-dev 2004-05-06 09:16:25 UTC
DEPEND is wrong, you don't need mono to use Qt#.

Unfortunatly there is no "virtual/cli" or something (most things work with pnet and mono, mono is just "hardcoded" in most packages).

I don't really know what should be done about this, but perhaps it's too early (still! ;) to deal with that, who knows.
Comment 5 Martin Honermeyer 2004-05-06 10:24:15 UTC
That's not really true. The newest versions of qt# don't work with pnet. But you are right, a virtual depend would be the better way, for the future.

http://qtcsharp.sourceforge.net/faq.html#SECTION00031000000000000000
Comment 6 Rainer Größlinger (RETIRED) gentoo-dev 2004-05-06 10:43:23 UTC
The FAQ is wrong here (or you could just call it "outdated"), pnet/qt# works for a long time now (and still does, I am using it right now as we speak).
Also, the INSTALL file of qt# (which is more up to date) says:

* Mono >= 0.30 or Portable.NET >= 0.6.2

Before 0.7.1, pnet was even required to build qt# (because of csant).

Anyway, I just think it's the wrong trend to let everything depend on mono although in fact mono isn't required, not for building and not for running it ;)
Comment 7 Caleb Tennis (RETIRED) gentoo-dev 2004-09-03 07:36:35 UTC
what about the qtsharp bindings in kdebindings?  are those different?
Comment 8 Martin Honermeyer 2004-09-03 07:43:17 UTC
Those are the same. It is explained at the home page: http://qtcsharp.sourceforge.net/
Comment 9 Caleb Tennis (RETIRED) gentoo-dev 2004-12-06 19:17:27 UTC
now available in kde-base/qtsharp
Comment 10 Martin Honermeyer 2004-12-07 04:28:42 UTC
Thanks! But why did you put it in kde-base? I think dev-dotnet would be far more appropriate..?
Comment 11 foser (RETIRED) gentoo-dev 2004-12-07 05:02:41 UTC
agreed, it really should be moved.
Comment 12 Carsten Lohrke (RETIRED) gentoo-dev 2004-12-07 05:24:37 UTC
It's a part of the splitted up kdebindings package. From my POV it does make sense to keep these packages in kde-base. At least the PyQt/PyKDE stuff (not exposed yet) is not congruent to the versions in dev-python/.
Comment 13 foser (RETIRED) gentoo-dev 2004-12-07 05:45:17 UTC
imho, if there is no 'physical' reason to have it in kde-base it should be in the logical place.

i can't comment on pykde or the whole why & how of the split-up, but it shouldn't result in two different versions anyway.
Comment 14 Carsten Lohrke (RETIRED) gentoo-dev 2004-12-07 06:16:14 UTC
>i can't comment on pykde or the whole why & how of the split-up, but it shouldn't result in two different versions anyway.

I don't know about the other stuff in kdebindings, but we can't do much about it that kde.org ships sip/pyqt/pykde versions, which differ from the ones from the original authors. The reasons why kde.org maintains them as part of kdebindings is, that the author of pykde does not have the time to keep up with newest kde versions (e.g. there is no pykde version compatible with kde-3.3.1 yet).

If there are similar issues with other bindings - annoying as it is - it makes sense to keep the ones from kdebindings in kde-base and maybe to have concurring ones in other categories. If this is not the case and qtsharp and "kdebindings-qtsharp" are identical, then I'll agree with you and instead the split-up kdebindings, the standalone tarball should be used, by a dev-dotnet/qtsharp ebuild.
Comment 15 foser (RETIRED) gentoo-dev 2004-12-07 06:45:02 UTC
In such a situation i would choose to support the best-maintained bindings, not both of them, I think that is too risky & confusing to users. I think it's strange bindings get treated like that by the kde team & there is not a single repository for development.
Comment 16 Carsten Lohrke (RETIRED) gentoo-dev 2004-12-07 07:54:09 UTC
foser: It's not that simple. The versions in kdebindings are older, patched ones, so pykde works with the new kde version. On the other hand this does not justify, that users of PyQt, want or should have to live with older versions. I did not really look into it, yet. Maybe it's possible only to extract pykde from kdebindings. But the bug is about Qt# anyways and I don't know how this bindings are handled.
Comment 17 Dan Armak (RETIRED) gentoo-dev 2004-12-08 11:48:40 UTC
I want to make sure - is the kdebindings/qtsharp package exactly the same as
the independant 0.7.1 package? Can we forget about qtcsharp.sf.net releases
from now on?
Comment 18 Rainer Größlinger (RETIRED) gentoo-dev 2004-12-08 12:32:53 UTC
Just a little note:

The ebuild has no keywords and ewarn says that it won't build because csant is not available in portage, that's not entirely true.
csant is part of the DotGNU Portable.NET toolchain (dev-dotnet/pnet) and thus, qtsharp will build on your favorite GNU box :)

But that "problem" solved automatically since the latest version from the qtcsharp module on sourceforge (released 9 months ago, hum...) doesn't require csant anymore.

Though, I don't know if that applies to the qtsharp stuff extracted from kdebindings, too.
Comment 19 Rainer Größlinger (RETIRED) gentoo-dev 2004-12-08 12:35:26 UTC
err, just to clarify:

With "The ebuild has no keywords [...]" I did *not* mean that it should be keyworded, just read that wording in the ChangeLog, don't know why I mentioned it ;)
Comment 20 Dan Armak (RETIRED) gentoo-dev 2004-12-08 12:45:03 UTC
Yes, it has no keywords because it can't be build without csant, and I didn't
know Gentoo had csant :-)

I thought it needs it because the docs that come with it (in kdebindings) say
so. Can someone comment on the kdebindings-qtcsharp.sf.net differences please?
I don't want to spend my time on trying to make the wrong version build.
I only have to do with the 'kde' in kdebindings - I don't actually use qtsharp
:-) What app (preferrably in portage) uses/needs qtsharp, so that I can test
against it?
Comment 21 Martin Honermeyer 2004-12-08 13:36:08 UTC
Sorry, I have to say that kdebindings isn't up-to-date any more. Version 0.7.1 from qtcsharp.sf.net (QTSHARP-0_7_1_BRANCH in Sourceforge CVS) is the most current version! Moreover, work on the current version has been stopped in favor of a new approach (called Bugtussle), which is developed entirely in Sourceforge CVS.

This means we really have to use the tarball from the Sourceforge site, sorry.
Comment 22 Peter Johanson (RETIRED) gentoo-dev 2005-01-25 19:53:08 UTC
*** Bug 42180 has been marked as a duplicate of this bug. ***
Comment 23 Dan Armak (RETIRED) gentoo-dev 2005-01-28 07:25:42 UTC
I'd like to, um, disassociate myself from this ebuild since I don't use qtsharp
and due to the current version not being developed anymore as per comment #22.
So don't expect me to do anything more for it...

This is assigned to dotnet@ anyway :-) When an uptodate ebuild is committed we
can remove kde-base/qtsharp.
Comment 24 Ioannis Aslanidis (RETIRED) gentoo-dev 2006-09-25 06:53:11 UTC
Version 0.7.1 was the last one. No updates since March 18, 2004. Their webpage is unmaintained, their IRC channel is empty.

Is it time to drop this request?
Comment 25 Ioannis Aslanidis (RETIRED) gentoo-dev 2006-09-25 08:34:35 UTC
Dropping.
Comment 26 Caleb Tennis (RETIRED) gentoo-dev 2006-09-25 09:02:06 UTC
I would.  I think Qyoto is the replacement for this, and the development seems quite active.
Comment 27 Ioannis Aslanidis (RETIRED) gentoo-dev 2006-09-25 09:11:19 UTC
I dropped it with latexer's permission. You are right about the Qyoto replacement. For what I see Qyoto is part of Kimono. I fail to locate their home page though. Any clues?