[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aperi-dev] Full support for Solaris?
|
Dale,
thanks for the patch.
In the next email, I'm sending 2 files
directly to you (not the entire list):
cclog_115_20070809A_solaris2.zip
(for SPARC)
cclog_115_20070809A_solaris2-amd.zip
(for x86)
I have not used these packages (no solaris
box). So perhaps you can give them a try and then we can check them
into the Aperi project based on your results (early beginnings of Solaris
support). I hope this is helpful to you.
I'll work on incorporating that patch
into the code base. Have a great holiday!
Todd Singleton
Software Engineer, Tivoli, IBM
Menlo Park, CA
email: toddsing@xxxxxxxxxx
Dale Ghent <daleg@xxxxxxxxxxxxx>
Sent by: aperi-dev-bounces@xxxxxxxxxxx
08/29/2007 09:48 PM
|
Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx> |
|
|
To
| Aperi Development <aperi-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| Re: [aperi-dev] Full support for Solaris? |
|
On Aug 29, 2007, at 1:35 PM, Khan M Tasinga wrote:
>
> Hey Dale,
>
> It's nice to hear from another person interested in Aperi! Here are
> some initial notes / thoughts related to what it'd take to get
> everything up and running on Solaris:
>
> When we (IBM) made our initial contribution to Eclipse, we only
> made sure to include all of the platform-specific code required to
> make everything work on Windows and Linux (for both, the 32-bit x86
> flavors). Platform-specific code for Solaris does exist. It would
> just need to be made available.
Is there a Legal vetting process that code must go through prior to
be committed to the repository? I'd like to take a look at that first
before trying to re-implement something that may already exist. I
already see bits of Solaris code and references sprinkled
throughout... so hopefully there's a a chance that could happen?
I realized after starting tonight that whether any existing Solaris
code is made available or not, the prospect of porting hinges on the
availability of this cclog tool. I think I would have EventScanner
working tonight if that were available.
BTW, here's a patch for you all. I noticed that in the Linux
EventScanner code, you're calling close() instead of fclose() on a
FILE-type stream, not a file descriptor. It's just something I
happened to catch as I was going through the code.
/dale_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev
Attachment:
lnx-eventscanner.diff
Description: Binary data
