getdata-devel — General discussion of GetData development.

Re: [getdata-devel] getdata on OS X

[Ted K. <tsk...@gm...>]

Thanks, I'll go play with trunk then!

-Ted

On Aug 31, 2010, at 7:42 PM, D. V. Wiebe wrote:

> On Tue, Aug 31, 2010 at 09:03:42AM -0700, Ted Kisner wrote:
>> Hi there Don (and others),
>> 
>> I have been trying to build getdata 0.6.3 on OS X with gcc 4.4 from macports.  There is a problem on this OS with the various largefile support things in getdata.
>> 
>> The compiler defines _LARGEFILE64_SOURCE, but does not define off64_t.  In getdata.h, this breaks.
>> 
>> There are probably many ways to fix this, but I was wondering:  how do you feel about removing all off_t / off64_t variants (which are system dependent) from the public API and using only types that are guaranteed to be 64bit in stdint.h / inttypes.h (int64_t).  Internally, these could be mapped to either off_t or off64_t depending on the configure checks.
>> 
>> This way there would be a cleaner separation of system-dependent things (in the internal header) and generic declarations (in getdata.h).
>> 
>> I realize that changing function signatures in the public API is painful...
>> 
>> If you think this is a useful thing to try, I could give it a go and circulate a patch to this list.
>> 
>> cheers,
>> 
>> -Ted
> 
> Hey Ted,
> 
> This and other OS X build issues have already been fixed in trunk.  (Or,
> at least they were fixed a month or so ago when I last tried compiling
> on Snow Leopard.)
> 
> I was planning to release an OS X-supporting 0.7.0 with these improvements
> in August, but then this kst-msvc thing came up.  Subsequently I got
> interrupted by other work.  So August is unlikely, but September...
> 
> Big caveat: in addition to OS X and Windows support, 0.7 (and trunk)
> breaks API compatibility with previous versions.  "Breaks" might not be
> a strong enough verb.
> 
> Check out the SVN if you're interested.  If you get impatient for a
> release let me know, and I can see whether buttoning up what's there now
> would be worth it.
> 
> Cheers,
> -dvw
> -- 
> D. V. Wiebe
> ge...@ke...
> http://getdata.sourceforge.net/

Re: [getdata-devel] getdata on OS X

[D. V. W. <ge...@ke...>]

On Tue, Aug 31, 2010 at 09:03:42AM -0700, Ted Kisner wrote:
> Hi there Don (and others),
> 
> I have been trying to build getdata 0.6.3 on OS X with gcc 4.4 from macports.  There is a problem on this OS with the various largefile support things in getdata.
> 
> The compiler defines _LARGEFILE64_SOURCE, but does not define off64_t.  In getdata.h, this breaks.
> 
> There are probably many ways to fix this, but I was wondering:  how do you feel about removing all off_t / off64_t variants (which are system dependent) from the public API and using only types that are guaranteed to be 64bit in stdint.h / inttypes.h (int64_t).  Internally, these could be mapped to either off_t or off64_t depending on the configure checks.
> 
> This way there would be a cleaner separation of system-dependent things (in the internal header) and generic declarations (in getdata.h).
> 
> I realize that changing function signatures in the public API is painful...
> 
> If you think this is a useful thing to try, I could give it a go and circulate a patch to this list.
> 
> cheers,
> 
> -Ted

Hey Ted,

This and other OS X build issues have already been fixed in trunk.  (Or,
at least they were fixed a month or so ago when I last tried compiling
on Snow Leopard.)

I was planning to release an OS X-supporting 0.7.0 with these improvements
in August, but then this kst-msvc thing came up.  Subsequently I got
interrupted by other work.  So August is unlikely, but September...

Big caveat: in addition to OS X and Windows support, 0.7 (and trunk)
breaks API compatibility with previous versions.  "Breaks" might not be
a strong enough verb.

Check out the SVN if you're interested.  If you get impatient for a
release let me know, and I can see whether buttoning up what's there now
would be worth it.

Cheers,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] Commit list

[D. V. W. <ge...@ke...>]

On Thu, Jul 29, 2010 at 12:06:03PM +0200, Peter K?mmel wrote:
> Seems there is no commit list.
> 
> What about creating "getdata-commits"?
> So all changes would be easy traceable.
> 
> Peter

Heh, sure.

I suspect you think there's more activity on GetData than there
actually is, but if you want it, I'll see what I can do.

Cheers,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] GETDATA_C89_API

[D. V. W. <ge...@ke...>]

On Thu, Jul 29, 2010 at 12:01:19PM +0200, Peter K?mmel wrote:
> >> Additionally maybe we catch some wrong implicit casts when compiling
> >> with the stronger typechecks of C++. For instance I wondered about
> >> this in add.c's _GD_Add function:
> >>
> >>     E->cm[i] = E->m[i];
> >>     E->cb[i] = E->b[i];
> >>
> >> cm[i] is complex number, but m[i] is only a double:
> > 
> > Yeah, I'm relying on the mandated behaviour of C99 type promotion here.
> > This only happens when the parameters are purely real, so I want cm[i]
> > to be equal to m[i].  C99 says this assignment will result in what I
> > want, ie.:
> > 
> > creal(cm[i]) = m[i]
> > cimag(cm[i]) = 0
> > 
> > I can't imagine what C++ might think about this, but since C++-98
> > doesn't know about C99-complex data storage, I wouldn't be surprised if
> > it complains.
> 
> When I use std::complex for E->cm also C++ compiles the original code.
> 
> Therefore, not supporting C89 compilers, I think the best and most generic
> route would be to make the code C++ compilable. Find attached a patch
> with the necessary changes for compiling add.c, most is straight forward.
> 
> If you also think this the way to go I could port the rest of the code
> and send patches to the list.
> 
> Peter

Peter,

Sorry for the delayed response.  I've been distracted by other things.

I'm a bit leery of doing it this way since it relies on std::complex
storing its data in RAM in Fortran order, when the C++98 standard leaves
the storage format of std::complex implementation dependent.  (The
proposed C++0x standard intends to fix this, but let's not hold our
breath for that.)

I think it might be best to simply choose the lowest common denominator,
and do the C89 thing.  Unfortunately, there are now public functions
which pass complex data by value, so I'll have to figure out what to do
about that.

I haven't been keeping up with the kst mailing list.  Did you manage to
compile GetData under MSVC?  Also, can you remind me: does kst2 link to
the C++ bindings, or does it use GetData's C API directly?  Oh, and does
kst2 make use of native complex data?  Or is it still doing everything
in doubles?

Cheers,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

[getdata-devel] getdata on OS X

[Ted K. <tsk...@gm...>]

Hi there Don (and others),

I have been trying to build getdata 0.6.3 on OS X with gcc 4.4 from macports.  There is a problem on this OS with the various largefile support things in getdata.

The compiler defines _LARGEFILE64_SOURCE, but does not define off64_t.  In getdata.h, this breaks.

There are probably many ways to fix this, but I was wondering:  how do you feel about removing all off_t / off64_t variants (which are system dependent) from the public API and using only types that are guaranteed to be 64bit in stdint.h / inttypes.h (int64_t).  Internally, these could be mapped to either off_t or off64_t depending on the configure checks.

This way there would be a cleaner separation of system-dependent things (in the internal header) and generic declarations (in getdata.h).

I realize that changing function signatures in the public API is painful...

If you think this is a useful thing to try, I could give it a go and circulate a patch to this list.

cheers,

-Ted

[getdata-devel] Commit list

[Peter K. <syn...@gm...>]

Seems there is no commit list.

What about creating "getdata-commits"?
So all changes would be easy traceable.

Peter

Re: [getdata-devel] GETDATA_C89_API

[Peter K. <syn...@gm...>]

> 
>> Seeing this I think about compiling as C++. Is this an option?
>> We would need more explicit casts (e.g. malloc returns void* only)
>> or switch to new in case of C++.
> 
> Does C++ handle complex math?

Yes, std::complex.

> 
>> Additionally maybe we catch some wrong implicit casts when compiling
>> with the stronger typechecks of C++. For instance I wondered about
>> this in add.c's _GD_Add function:
>>
>>     E->cm[i] = E->m[i];
>>     E->cb[i] = E->b[i];
>>
>> cm[i] is complex number, but m[i] is only a double:
> 
> Yeah, I'm relying on the mandated behaviour of C99 type promotion here.
> This only happens when the parameters are purely real, so I want cm[i]
> to be equal to m[i].  C99 says this assignment will result in what I
> want, ie.:
> 
> creal(cm[i]) = m[i]
> cimag(cm[i]) = 0
> 
> I can't imagine what C++ might think about this, but since C++-98
> doesn't know about C99-complex data storage, I wouldn't be surprised if
> it complains.

When I use std::complex for E->cm also C++ compiles the original code.

Therefore, not supporting C89 compilers, I think the best and most generic
route would be to make the code C++ compilable. Find attached a patch
with the necessary changes for compiling add.c, most is straight forward.

If you also think this the way to go I could port the rest of the code
and send patches to the list.

Peter

Re: [getdata-devel] GETDATA_C89_API

[Peter K. <syn...@gm...>]

D. V. Wiebe wrote:
> On Wed, Jul 28, 2010 at 06:47:15PM +0200, Peter K?mmel wrote:
>> MSVC doesn't support C99, so I'm forced to use the macro GETDATA_C89_API.
>>
>> To test if GETDATA_C89_API is fully supported I simply defined it in the
>> generated getdata.h when compiling with gcc. But there where are many errors.
>>
>> Therefore my question: Is GETDATA_C89_API fully supported?
>>
>> Peter
> 
> Unfortunately, building GetData requires a somewhat C99-compliant compiler. 
> 
> The GETDATA_C89_API macro only affects the public header file and is intended
> for code linking to libgetdata.  (Including, GetData's own C++ bindings, since
> C++-98 isn't ABI compatible with FORTRAN-style complex data.)

OK, then I misunderstood the macro.

> 
> I think the C99 only features that GetData makes use of are:
> * complex math (complex.h)
> * standard types (inttypes.h)
> 
> and then some things which most C compilers already did:
> * // comments
> * long long int
> * intermixing of variable declarations and code
> * __VAR_ARGS__ CPP macros
> 
> The standard types stuff can be sorted by autotools.  The complex math
> would be trickier, but I think it could be done.  I can add "C89-ise" to
> the TODO.
> 
> Does kst even support complex data?  The easy solution might be to have
> a C89 build of GetData which just ifdef out the complex math parts.  If
> MSVC has partial C99 support, maybe we can work around the parts it's
> missing?

Before fiddling around with MS's obsolete compiler I would prefer
to compile all with C++. See next mail.

Peter


> 
> Let me know what you need,
> -dvw

Re: [getdata-devel] GETDATA_C89_API

[D. V. W. <ge...@ke...>]

On Wed, Jul 28, 2010 at 06:47:15PM +0200, Peter K?mmel wrote:
> MSVC doesn't support C99, so I'm forced to use the macro GETDATA_C89_API.
> 
> To test if GETDATA_C89_API is fully supported I simply defined it in the
> generated getdata.h when compiling with gcc. But there where are many errors.
> 
> Therefore my question: Is GETDATA_C89_API fully supported?
> 
> Peter

Unfortunately, building GetData requires a somewhat C99-compliant compiler. 

The GETDATA_C89_API macro only affects the public header file and is intended
for code linking to libgetdata.  (Including, GetData's own C++ bindings, since
C++-98 isn't ABI compatible with FORTRAN-style complex data.)

I think the C99 only features that GetData makes use of are:
* complex math (complex.h)
* standard types (inttypes.h)

and then some things which most C compilers already did:
* // comments
* long long int
* intermixing of variable declarations and code
* __VAR_ARGS__ CPP macros

The standard types stuff can be sorted by autotools.  The complex math
would be trickier, but I think it could be done.  I can add "C89-ise" to
the TODO.

Does kst even support complex data?  The easy solution might be to have
a C89 build of GetData which just ifdef out the complex math parts.  If
MSVC has partial C99 support, maybe we can work around the parts it's
missing?

Let me know what you need,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] GETDATA_C89_API

[Peter K. <syn...@gm...>]

Peter Kümmel wrote:
> MSVC doesn't support C99, so I'm forced to use the macro GETDATA_C89_API.
> 
> To test if GETDATA_C89_API is fully supported I simply defined it in the
> generated getdata.h when compiling with gcc. But there where are many errors.
> 
> Therefore my question: Is GETDATA_C89_API fully supported?
>

I've only changed add.c to remove most compiler errors and I get
attached patch. Most stuff is moving arond variable declarations.

Seeing this I think about compiling as C++. Is this an option?
We would need more explicit casts (e.g. malloc returns void* only)
or switch to new in case of C++.

Additionally maybe we catch some wrong implicit casts when compiling
with the stronger typechecks of C++. For instance I wondered about
this in add.c's _GD_Add function:

    E->cm[i] = E->m[i];
    E->cb[i] = E->b[i];

cm[i] is complex number, but m[i] is only a double:

    struct { /* LINCOM */
      double m[GD_MAX_LINCOM];
      GD_DCOMPLEXM(cm[GD_MAX_LINCOM]);


Peter

[getdata-devel] GETDATA_C89_API

[Peter K. <syn...@gm...>]

MSVC doesn't support C99, so I'm forced to use the macro GETDATA_C89_API.

To test if GETDATA_C89_API is fully supported I simply defined it in the
generated getdata.h when compiling with gcc. But there where are many errors.

Therefore my question: Is GETDATA_C89_API fully supported?

Peter

Re: [getdata-devel] Next step

[Peter K. <syn...@gm...>]

Am Donnerstag, den 22.07.2010, 02:22 -0500 schrieb Barth Netterfield:
> On Thu, Jul 22, 2010 at 12:41 AM, Peter Kümmel <syn...@gm...> wrote:
> > Am Mittwoch, den 21.07.2010, 19:03 -0500 schrieb Barth Netterfield:
> >> Will you be adding cmake to kst as well?
> >
> > A good question. At the moment we don't have problems using qmake
> > for kst2. The only problem is the configure step, there is cmake
> > much better than qmake. So, when there are more and more dependencies
> > to other libraries a switch to cmake would make things simpler.
> >
> > KDE integration is a other argument. Wasn't this the reason for kst1
> > to use cmake?
> 
> Yes.  I think there are a lot of requirements for making kst2 a KDE
> app, like using KDE for example.  CMAKE is one of them.

OK, then cmake is on my list.

(seems we are off topic on getdata-devel)

Peter

Re: [getdata-devel] Next step

[Peter K. <syn...@gm...>]

Am Mittwoch, den 21.07.2010, 19:03 -0500 schrieb Barth Netterfield:
> Will you be adding cmake to kst as well?

A good question. At the moment we don't have problems using qmake
for kst2. The only problem is the configure step, there is cmake
much better than qmake. So, when there are more and more dependencies
to other libraries a switch to cmake would make things simpler.

KDE integration is a other argument. Wasn't this the reason for kst1
to use cmake?

Peter

Re: [getdata-devel] Next step

[D. V. W. <ge...@ke...>]

On Thu, Jul 22, 2010 at 01:51:48AM +0200, Peter K?mmel wrote:
> Am Mittwoch, den 21.07.2010, 18:45 -0500 schrieb Barth Netterfield:
> > > Windows is from a other planet ;) No common place to install libraries,
> > > most apps ship all libs which they need in their own folder.
> > 
> > So... would it make sense for the kst windows package to include getdata?
> 
> I would link getdata statically into the datasource plugin for dirfile.
> 
> Peter

So, then it sounds like you should add cmake files to getdata regardless
of whether there's a stand-alone getdata package for windows, anyways.

-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] Next step

[Peter K. <syn...@gm...>]

Am Mittwoch, den 21.07.2010, 18:45 -0500 schrieb Barth Netterfield:
> > Windows is from a other planet ;) No common place to install libraries,
> > most apps ship all libs which they need in their own folder.
> 
> So... would it make sense for the kst windows package to include getdata?

I would link getdata statically into the datasource plugin for dirfile.

Peter

Re: [getdata-devel] Next step

[Peter K. <syn...@gm...>]

Am Mittwoch, den 21.07.2010, 16:38 -0700 schrieb D. V. Wiebe:
> > > What can cmake do that the autotools can't?
> > 
> > When developing on Windows I use Visual Studio because of the debugger,
> > and cmake could generate project files for Studio. This way it would
> > also be possible to debug into getdir code. Another point is that static
> > linking is not possible with mingw builds when using msvc. But when your
> > win32 release is production quality and I never had to touch the code,
> > it's maybe simpler to use your build. But I always prefer to build
> > everything with only one toolchain.
> 
> Yes, I can see how project files would be handy.  I have no real
> objections to adding cmake files to GetData, although I'm willing to try
> providing a binary Windows package that you could use, if it would make
> things easier for you.

I just build gettext on Linux, and what I see most work would be to add
all the configure checks which are necessary when cmake is used on
Linux. But first I try a Windows-only version.


BTW, on Linux cmake could generate these make/project files:

Unix Makefiles                = Generates standard UNIX makefiles.
CodeBlocks - Unix Makefiles   = Generates CodeBlocks project files.
Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project files.
KDevelop3                     = Generates KDevelop 3 project files.
KDevelop3 - Unix Makefiles    = Generates KDevelop 3 project files.

And QtCreator could use CodeBlocks project files

Peter

Re: [getdata-devel] Next step

[Barth N. <bar...@gm...>]

> Windows is from a other planet ;) No common place to install libraries,
> most apps ship all libs which they need in their own folder.

So... would it make sense for the kst windows package to include getdata?

Re: [getdata-devel] Next step

[Peter K. <syn...@gm...>]

Am Mittwoch, den 21.07.2010, 16:33 -0700 schrieb D. V. Wiebe:
> On Wed, Jul 21, 2010 at 05:04:21PM -0500, Barth Netterfield wrote:
> > On Wed, Jul 21, 2010 at 4:25 PM, D. V. Wiebe <ge...@ke...> wrote:
> > > The intent is that the upcoming 0.7 release should be usable on win32.
> > > (There are some corner cases I'm not sure about regarding two processes
> > > attempting to use the same dirfile at the same time, resulting from the
> > > non-POSIX-ness of the MS CRT, but, meh...)
> > 
> > Are these related to writing only?
> 
> Yeah, writing using GetData.
> 
> > 
> > > What can cmake do that the autotools can't?
> > 
> > Be part of KDE.  But I'm not sure if that is relevant.  Is your plan
> > to provide windows packages?
> 
> I will if no one else is willing to take on the job.  Where do system
> libraries live in windows?  /usr/windows?

Windows is from a other planet ;) No common place to install libraries,
most apps ship all libs which they need in their own folder.

> 
> -dvw

Re: [getdata-devel] Next step

[D. V. W. <ge...@ke...>]

On Wed, Jul 21, 2010 at 04:33:12PM -0700, D. V. Wiebe wrote:
> On Wed, Jul 21, 2010 at 05:04:21PM -0500, Barth Netterfield wrote:
> > On Wed, Jul 21, 2010 at 4:25 PM, D. V. Wiebe <ge...@ke...> wrote:
> > > The intent is that the upcoming 0.7 release should be usable on win32.
> > > (There are some corner cases I'm not sure about regarding two processes
> > > attempting to use the same dirfile at the same time, resulting from the
> > > non-POSIX-ness of the MS CRT, but, meh...)
> > 
> > Are these related to writing only?
> 
> Yeah, writing using GetData.
> 
> > 
> > > What can cmake do that the autotools can't?
> > 
> > Be part of KDE.  But I'm not sure if that is relevant.  Is your plan
> > to provide windows packages?
> 
> I will if no one else is willing to take on the job.  Where do system
> libraries live in windows?  /usr/windows?

Hey, let's pretend I wrote "c:" instead of "/usr" up there...

-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] Next step

[D. V. W. <ge...@ke...>]

On Wed, Jul 21, 2010 at 05:04:21PM -0500, Barth Netterfield wrote:
> On Wed, Jul 21, 2010 at 4:25 PM, D. V. Wiebe <ge...@ke...> wrote:
> > The intent is that the upcoming 0.7 release should be usable on win32.
> > (There are some corner cases I'm not sure about regarding two processes
> > attempting to use the same dirfile at the same time, resulting from the
> > non-POSIX-ness of the MS CRT, but, meh...)
> 
> Are these related to writing only?

Yeah, writing using GetData.

> 
> > What can cmake do that the autotools can't?
> 
> Be part of KDE.  But I'm not sure if that is relevant.  Is your plan
> to provide windows packages?

I will if no one else is willing to take on the job.  Where do system
libraries live in windows?  /usr/windows?

-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] Next step

[Peter K. <syn...@gm...>]

Am Mittwoch, den 21.07.2010, 14:25 -0700 schrieb D. V. Wiebe:
> On Wed, Jul 21, 2010 at 11:05:24AM -0400, Matthew D Truch wrote:
> > > Yes, I also thought, it will be first a getdata only project. 
> > > I would start with asking if I could add a build system for windows:
> > > CMake files which will reside in a cmake folder, so the source code 
> > > will not be polluted with CMakeLists.txt files (GetData looks very
> > > GNU-ish, so I don't know how allergic people are against windows
> > > specific changes.)
> > 
> > Definitely coordinate with Don.  Rumor has it he is already working on
> > getting it to compile under windows (with MinGW and Msys).  
> 
> Indeed, the GetData head compiles on win32 under MinGW+Msys, using the
> Microsoft CRT (and also under Cygwin, using newlib).  Well, at least it did
> the last time I tried.
> 
> The intent is that the upcoming 0.7 release should be usable on win32.
> (There are some corner cases I'm not sure about regarding two processes
> attempting to use the same dirfile at the same time, resulting from the
> non-POSIX-ness of the MS CRT, but, meh...)
> 
> What can cmake do that the autotools can't?

When developing on Windows I use Visual Studio because of the debugger,
and cmake could generate project files for Studio. This way it would
also be possible to debug into getdir code. Another point is that static
linking is not possible with mingw builds when using msvc. But when your
win32 release is production quality and I never had to touch the code,
it's maybe simpler to use your build. But I always prefer to build
everything with only one toolchain.

Peter



> 
> Cheers,
> -dvw

Re: [getdata-devel] Next step

[Barth N. <bar...@gm...>]

On Wed, Jul 21, 2010 at 4:25 PM, D. V. Wiebe <ge...@ke...> wrote:
> The intent is that the upcoming 0.7 release should be usable on win32.
> (There are some corner cases I'm not sure about regarding two processes
> attempting to use the same dirfile at the same time, resulting from the
> non-POSIX-ness of the MS CRT, but, meh...)

Are these related to writing only?

> What can cmake do that the autotools can't?

Be part of KDE.  But I'm not sure if that is relevant.  Is your plan
to provide windows packages?

Re: [getdata-devel] Next step

[D. V. W. <ge...@ke...>]

On Wed, Jul 21, 2010 at 11:05:24AM -0400, Matthew D Truch wrote:
> > Yes, I also thought, it will be first a getdata only project. 
> > I would start with asking if I could add a build system for windows:
> > CMake files which will reside in a cmake folder, so the source code 
> > will not be polluted with CMakeLists.txt files (GetData looks very
> > GNU-ish, so I don't know how allergic people are against windows
> > specific changes.)
> 
> Definitely coordinate with Don.  Rumor has it he is already working on
> getting it to compile under windows (with MinGW and Msys).  

Indeed, the GetData head compiles on win32 under MinGW+Msys, using the
Microsoft CRT (and also under Cygwin, using newlib).  Well, at least it did
the last time I tried.

The intent is that the upcoming 0.7 release should be usable on win32.
(There are some corner cases I'm not sure about regarding two processes
attempting to use the same dirfile at the same time, resulting from the
non-POSIX-ness of the MS CRT, but, meh...)

What can cmake do that the autotools can't?

Cheers,
-dvw
-- 
D. V. Wiebe
ge...@ke...
http://getdata.sourceforge.net/

Re: [getdata-devel] Next step

[Matthew D T. <ma...@tr...>]

> Yes, I also thought, it will be first a getdata only project. 
> I would start with asking if I could add a build system for windows:
> CMake files which will reside in a cmake folder, so the source code 
> will not be polluted with CMakeLists.txt files (GetData looks very
> GNU-ish, so I don't know how allergic people are against windows
> specific changes.)

Definitely coordinate with Don.  Rumor has it he is already working on
getting it to compile under windows (with MinGW and Msys).  

-- 
"Physics isn't difficult; it's just weird. -- Vincent Icke"
--------------------------
Matthew Truch
Department of Physics and Astronomy
University of Pennsylvania
ma...@tr...
http://matt.truch.net/

Re: [getdata-devel] Next step

[Peter K. <syn...@gm...>]

> > 
> > You will probably want to become part of
> > get...@li..., and check with Don about what
> > status things are at in the port.
> 
Yes, I also thought, it will be first a getdata only project. 
I would start with asking if I could add a build system for windows:
CMake files which will reside in a cmake folder, so the source code 
will not be polluted with CMakeLists.txt files (GetData looks very
GNU-ish, so I don't know how allergic people are against windows
specific changes.)

Peter