Red Hat bugs...

[Ralph Mack]

OK. I tweaked the generated configure script this morning to reduce the 
requirement from Qt 3.1 to 3.0, built the
program, and ran it. The new version that I built (which reports itself 
as 2.1.4) appears to behave properly w.r.t. jumping to source from 
reported errors. I notice from the ChangeLog that F at lk applied a fix on 
the 31st for the problem, the day before I built. (I would have tweaked 
in a more original place than the generated configure script but I'm 
still sorting through the various layers of .in, .am, .in.in, etc. to 
figure out how all this layers together - there's a bunch of 
superstructure there over vanilla automake - and figured I'd just get 
something done first.)

In the absence of further information I can only presume that the Qt 
3.1 requirement was driven by either a library bug causing a KDevelop 
bug or a library feature required for a KDevelop feature. Since the 
code built successfully, the former seems likelier than the latter.

So I figured out the answers to most of my original questions. As I dig 
further into the Linux world, I am getting more comfortable with the 
radical notion of learning things by trying them rather than by trying 
to find the canonical answer from some authority, but it is a difficult 
adjustment. Most of my past work has been heavily standards-based, 
where it doesn't matter if something works unless it is also 
well-formed. I apologize for the noise.

However, pragmatically, my little hack into the configure script has me 
wondering:
- What feature of kdevelop won't work with the version that I built 
against Qt 3.0.5? Was it egregious?
- Assuming this was the only deviation, can I safely use what I made as 
my development environment going forward?

Ralph

On Saturday, Nov 2, 2002, at 00:16 US/Eastern, Ralph Mack wrote:

> Uh-oh... The code from CVS requires Qt 3.1.0 rather than 3.0.5 in 
> order to pass configure checks.
>
> Red Hat 8.0 has KDevelop 2.1.3 built against KDE 3.0.3-8 and it 
> doesn't say which version of Qt was used.
> What's the best way to build something I can debug without affecting 
> the as-installed system by updating
> the Qt version on it? Is there another CVS tag I should use?
>
> Ralph
>
> On Friday, Nov 1, 2002, at 18:36 US/Eastern, Ralph Mack wrote:
>
>> Hello, all,
>>
>> I'm trying to use KDevelop on Red Hat and running into about the same 
>> bug everybody else is.
>> So I figured the weekend is coming up and how hard can it be and 
>> grabbed the KDE_2_2_BRANCH
>> according to the instructions on the web site. It is building now.
>>
>> I don't want to deploy it over my existing stuff. Instead I'd like to 
>> run it where it is built.
>> I figure I'll verify that the problems happen with the 
>> built-from-source version as well as the
>> installed-from-RPM-during-upgrade version and then proceed to use the 
>> installed version to debug
>> the problem in the built-from-source version, using one of my own 
>> projects with a judiciously
>> inserted bug as the guinea pig.
>>
>> 1. How do I run the new KDevelop from its own tree? Is it as simple 
>> as going to the executable
>>    directory and executing it or do I have to set some environment 
>> variables?
>> 2. Can I debug in the way I've outlined? Can I use one KDevelop to 
>> debug another as it operates
>>    on my own code?
>>
>> Thanks,
>>
>> Ralph
>>
>>
>> -
>> to unsubscribe from this list send an email to 
>> kdevelop-request at kdevelop.org with the following body:
>> unsubscribe ªyour-email-address´
>
>
> -
> to unsubscribe from this list send an email to 
> kdevelop-request at kdevelop.org with the following body:
> unsubscribe »your-email-address«


-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«