[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    FW: ClearCase integration with QMake project
From:       "Patrick Noffke" <patrickn () adpro ! com ! au>
Date:       2005-09-05 23:19:30
Message-ID: 21E1E750F7A66649A99576799021BBD81572AE () zulu ! adpro ! com ! au
[Download RAW message or body]

Perhaps folks on this list will be able to help with this.

-----Original Message-----
From: Mailing list agent [mailto:mdom@barney.cs.uni-potsdam.de]On Behalf
Of Patrick Noffke
Sent: Monday, 5 September 2005 2:44 PM
To: kdevelop@kdevelop.org
Subject: RE: ClearCase integration with QMake project


Thank you, that helps.  Unfortunately, our directory structure doesn't follow the \
/view/<view_name>/vobs/<project> heirarchy.  I am investigating changing the \
clearcasepart to use cleartool for determining whether to present the ClearCase \
context menu.

My initial thought is to run:  cleartool pwv.

If you have a view set and are within a vob directory, this command will return \
output such as:

Working directory view: <view_name>
Set view: <view_name>

If you have a view set and are not within a vob directory, this command will return \
output such as:

Working directory view: ** NONE **
Set view: <view_name>

If you do not have a view set, but are within a vob directory, this command will \
return output such as:

Working directory view: <view_name>
Set view: ** NONE **

Finally, if you do not have a view set, and are not within a vob directory, this \
command will return:

Working directory view: ** NONE **
Set view: ** NONE **

So it would seem searching the output of this command for the string "** NONE **" \
would be sufficient to decide if the clearcase context menu should be shown.  

I believe this approach would work with snapshot views as well.  The "working \
directory view" is determined (by clearcase) by going up the directory tree until it \
finds a .view.dat file.  If so, and a view is set, the 'cleartool pwv' output should \
not contain the string "** NONE **".

My concern is how and when to run the cleartool binary.  QProcess doesn't appear have \
a way to start a process, read its output, and wait for completion, all from within a \
single function.  I don't know enough about the internals of the signals and slots \
mechanism, but if it's some sort of main event loop, I believe that if I tried \
blocking (e.g. on a semaphore) in the contextMenu function until the cleartool \
process exited, the QProcess slots would never get called.  And the place where I'd \
want to signal the semaphore would be in a slot receiving the QProcess \
processExited() signal.  I also don't really like the idea of blocking until the \
process completes.

Can anyone suggest an appropriate "how and when" to run cleartool for the purpose of \
determining if the ClearCase menu should be presented?

Regards,
Patrick

-----Original Message-----
From: Mailing list agent [mailto:mdom@barney.cs.uni-potsdam.de]On Behalf
Of Amilcar do Carmo Lucas
Sent: Friday, 2 September 2005 6:13 PM
To: kdevelop@kdevelop.org
Subject: Re: ClearCase integration with QMake project


On Friday 02 September 2005 02:40, Patrick Noffke wrote:
> Does anyone know how to make ClearCase integration work with a QMake
> project?  I'm using ClearCase 2003.06.01, and I'm working within dynamic
> views.  My KDevelop version is 3.2.2 on a FC3 host, KDE version
> 3.4.2-0.fc3.2 Red Hat.

This is the info we can provide you with:
http://www.kdevelop.org/HEAD/doc/api/html/classClearcasePart.html

-- 
Amilcar Lucas
Current webmaster
The KDevelop project

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

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

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel


[prev in list] [next in list] [prev in thread] [next in thread]