This might be a bit too internal for the forum, but maybe still of interest
for more:
The HDF5 tools (h5dump, h5ls, ...) share common code via the tools library.
This is currently built as a static library and linked into the main executables.
It appears it would not be a big effort to modify it to be shared library/DLL
instead. There are two symbols that from the library are references as "external"
and are supposed to be defined in the main application. These would need to go
into the library itself instead to be able to build it as shared library. Not
a big deal.
If we can have the tools library available through header files and DLL for
user code as well, it has two advantages: once the executables are a bit
smaller (which is not really important these days), but secondly one could
also easier write user-modified versions of h5ls/h5dump etc., for instance
versions that use another VFD, or output data differently on dump etc.
As a DLL under windows, only addition required in the code were some
symbol export definitions. I'd be volunteering to contribute such.
Is there interest in such a patch?
Werner
···
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
211 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362
You made a very good suggestion. It is actual in our long-term plan to make
a set of public tools functions and also to make our current tools more modular.
Because of other priority, we do not have much resource to commit to the work.
However, we are working toward to this goal.
As for making some of the current function to be public and build as dll, you
are welcome to try. If there is no other issue (technical and non-technical),
we will be happy to include your contribution.
Thanks
--pc
Werner Benger wrote:
···
This might be a bit too internal for the forum, but maybe still of interest
for more:
The HDF5 tools (h5dump, h5ls, ...) share common code via the tools library.
This is currently built as a static library and linked into the main executables.
It appears it would not be a big effort to modify it to be shared library/DLL
instead. There are two symbols that from the library are references as "external"
and are supposed to be defined in the main application. These would need to go
into the library itself instead to be able to build it as shared library. Not
a big deal.
If we can have the tools library available through header files and DLL for
user code as well, it has two advantages: once the executables are a bit
smaller (which is not really important these days), but secondly one could
also easier write user-modified versions of h5ls/h5dump etc., for instance
versions that use another VFD, or output data differently on dump etc.
As a DLL under windows, only addition required in the code were some
symbol export definitions. I'd be volunteering to contribute such.
Not sure what you have as far as hardware for testing goes, but if you use the Git repository at www.gitorious.com/hdf5 then I can test any changes on OS X intel and Windows 7 x64. Just FYI.
Basically sign up for an account and clone the repository. We can then pull from your clone to test out changes.
···
___________________________________________________________
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jackson@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Mar 10, 2010, at 2:54 PM, Peter Cao wrote:
Werner,
You made a very good suggestion. It is actual in our long-term plan to make
a set of public tools functions and also to make our current tools more modular.
Because of other priority, we do not have much resource to commit to the work.
However, we are working toward to this goal.
As for making some of the current function to be public and build as dll, you
are welcome to try. If there is no other issue (technical and non-technical),
we will be happy to include your contribution.
Thanks
--pc
Werner Benger wrote:
This might be a bit too internal for the forum, but maybe still of interest
for more:
The HDF5 tools (h5dump, h5ls, ...) share common code via the tools library.
This is currently built as a static library and linked into the main executables.
It appears it would not be a big effort to modify it to be shared library/DLL
instead. There are two symbols that from the library are references as "external"
and are supposed to be defined in the main application. These would need to go
into the library itself instead to be able to build it as shared library. Not
a big deal.
If we can have the tools library available through header files and DLL for
user code as well, it has two advantages: once the executables are a bit
smaller (which is not really important these days), but secondly one could
also easier write user-modified versions of h5ls/h5dump etc., for instance
versions that use another VFD, or output data differently on dump etc.
As a DLL under windows, only addition required in the code were some
symbol export definitions. I'd be volunteering to contribute such.
but secondly one could
also easier write user-modified versions of h5ls/h5dump etc., for instance
versions that use another VFD, or output data differently on dump etc.
We have done exactly this. A modified H5Dump that uses our DSM based VFD so we can inspect the memory based files. We did it the messy way by making various copies of assorted h5tools stuff and tweaking them. So if and when you make your suggested changes, please let me know and I'll test them on our stuff, and help out if necessary.
attached is a patch to SVN version 18506 of HDF5 1.8 (today) which moves
the "progname" and "d_status" definitions into the tools library instead of
having them in the main application. This is required for building the tools
library as dll, since the dll can't reference external symbols defined in
the main application.
Instead I added four new functions to the tools library, h5tools_setprogname(),
h5tools_getprogname(), h5tools_setstatus(), h5tools_getstatus() which allow
to communicate those variables with the library.
So far it all compiled and run well under Linux 64, and I could build h5ls
under Windows with the h5tools library as dll.
I did *not* do an extensive check on other platforms or change anything
in the configure or hdf5 build system. It still builds the tools library
as a static library. Someone else who is more experience with the autoconf
tool would need to do that, but as far as it concerns the C source code,
those changes should do the job. There might be some undefined symbols
when building the other tools under Windows with a dll, since I didn't
check all of them, but if that happens, it's straightforward to just
add another dll export/import declaration (similar to those at the
h5tools_getprogname() etc. functions).
On Wed, 10 Mar 2010 14:54:13 -0500, Peter Cao <xcao@hdfgroup.org> wrote:
Werner,
You made a very good suggestion. It is actual in our long-term plan to make
a set of public tools functions and also to make our current tools more
modular.
Because of other priority, we do not have much resource to commit to the
work.
However, we are working toward to this goal.
As for making some of the current function to be public and build as
dll, you
are welcome to try. If there is no other issue (technical and
non-technical),
we will be happy to include your contribution.
Thanks
--pc
Werner Benger wrote:
This might be a bit too internal for the forum, but maybe still of
interest
for more:
The HDF5 tools (h5dump, h5ls, ...) share common code via the tools
library.
This is currently built as a static library and linked into the main
executables.
It appears it would not be a big effort to modify it to be shared
library/DLL
instead. There are two symbols that from the library are references as
"external"
and are supposed to be defined in the main application. These would
need to go
into the library itself instead to be able to build it as shared
library. Not
a big deal.
If we can have the tools library available through header files and
DLL for
user code as well, it has two advantages: once the executables are a bit
smaller (which is not really important these days), but secondly one
could
also easier write user-modified versions of h5ls/h5dump etc., for
instance
versions that use another VFD, or output data differently on dump etc.
As a DLL under windows, only addition required in the code were some
symbol export definitions. I'd be volunteering to contribute such.
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
211 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362
I'm not too familiar with git, last time I tried to install it under msys it
turned out to become messy, so I'm somewhat reluctant to go through this again.
Would you be able to test the SVN patch that I just sent to the list?
Not sure what you have as far as hardware for testing goes, but if you
use the Git repository at www.gitorious.com/hdf5 then I can test any
changes on OS X intel and Windows 7 x64. Just FYI.
Basically sign up for an account and clone the repository. We can then
pull from your clone to test out changes.
___________________________________________________________
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jackson@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Mar 10, 2010, at 2:54 PM, Peter Cao wrote:
Werner,
You made a very good suggestion. It is actual in our long-term plan
to make
a set of public tools functions and also to make our current tools
more modular.
Because of other priority, we do not have much resource to commit to
the work.
However, we are working toward to this goal.
As for making some of the current function to be public and build as
dll, you
are welcome to try. If there is no other issue (technical and non-
technical),
we will be happy to include your contribution.
Thanks
--pc
Werner Benger wrote:
This might be a bit too internal for the forum, but maybe still of
interest
for more:
The HDF5 tools (h5dump, h5ls, ...) share common code via the tools
library.
This is currently built as a static library and linked into the
main executables.
It appears it would not be a big effort to modify it to be shared
library/DLL
instead. There are two symbols that from the library are references
as "external"
and are supposed to be defined in the main application. These would
need to go
into the library itself instead to be able to build it as shared
library. Not
a big deal.
If we can have the tools library available through header files and
DLL for
user code as well, it has two advantages: once the executables are
a bit
smaller (which is not really important these days), but secondly
one could
also easier write user-modified versions of h5ls/h5dump etc., for
instance
versions that use another VFD, or output data differently on dump
etc.
As a DLL under windows, only addition required in the code were some
symbol export definitions. I'd be volunteering to contribute such.
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
211 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362
Thank you very much for your contribution and informing us the
progress of the work. I am glad that it works for you.
Jonathan Kim, our main tools developer, will take a look at the details.
Jonathan is on vacation now. As he has a long list of todo tasks, I don't
know when he will be able to work on this. We also need to know what
implication the change will have, such as will it work on all platforms?,
any extra work for our maintenance and support?
I can definitely see that the change is an improvement to the tools.
Thanks
--pc
···
Hi Peter,
attached is a patch to SVN version 18506 of HDF5 1.8 (today) which moves
the "progname" and "d_status" definitions into the tools library instead of
having them in the main application. This is required for building the tools
library as dll, since the dll can't reference external symbols defined in
the main application.
Instead I added four new functions to the tools library, h5tools_setprogname(),
h5tools_getprogname(), h5tools_setstatus(), h5tools_getstatus() which allow
to communicate those variables with the library.
So far it all compiled and run well under Linux 64, and I could build h5ls
under Windows with the h5tools library as dll.
I did *not* do an extensive check on other platforms or change anything
in the configure or hdf5 build system. It still builds the tools library
as a static library. Someone else who is more experience with the autoconf
tool would need to do that, but as far as it concerns the C source code,
those changes should do the job. There might be some undefined symbols
when building the other tools under Windows with a dll, since I didn't
check all of them, but if that happens, it's straightforward to just
add another dll export/import declaration (similar to those at the
h5tools_getprogname() etc. functions).
Werner
On Wed, 10 Mar 2010 14:54:13 -0500, Peter Cao <xcao@hdfgroup.org> wrote:
Werner,
You made a very good suggestion. It is actual in our long-term plan to make
a set of public tools functions and also to make our current tools more
modular.
Because of other priority, we do not have much resource to commit to the
work.
However, we are working toward to this goal.
As for making some of the current function to be public and build as
dll, you
are welcome to try. If there is no other issue (technical and
non-technical),
we will be happy to include your contribution.
Thanks
--pc
Werner Benger wrote:
This might be a bit too internal for the forum, but maybe still of
interest
for more:
The HDF5 tools (h5dump, h5ls, ...) share common code via the tools
library.
This is currently built as a static library and linked into the main
executables.
It appears it would not be a big effort to modify it to be shared
library/DLL
instead. There are two symbols that from the library are references as
"external"
and are supposed to be defined in the main application. These would
need to go
into the library itself instead to be able to build it as shared
library. Not
a big deal.
If we can have the tools library available through header files and
DLL for
user code as well, it has two advantages: once the executables are a bit
smaller (which is not really important these days), but secondly one
could
also easier write user-modified versions of h5ls/h5dump etc., for
instance
versions that use another VFD, or output data differently on dump etc.
As a DLL under windows, only addition required in the code were some
symbol export definitions. I'd be volunteering to contribute such.
the only platform-dependencies are for the windows-specific dll
import/export definitions, but they are protected by the appropriate #defines already. So no worries to expect here.
The change is actually pretty minimal, so I don't expect it to require
any more maintenance and support rather than remembering that one should
not declare those two symbols progname/d_status in the main application
(if someone writes a new tool) but use the according h5tools_ functions.
One could do more cleanup, since not all tools seem to use the h5tools
library, and also there are functions which pass the progname explicitly
even though it is already known implicitly by the h5tools library, but
I kept any changes to the minimum.
It should also be pretty easy to apply these changes to any further
version if it can't be integrated right now.
Werner
···
On Fri, 02 Apr 2010 14:18:40 -0400, Peter Cao <xcao@hdfgroup.org> wrote:
Hi Werner,
Thank you very much for your contribution and informing us the
progress of the work. I am glad that it works for you.
Jonathan Kim, our main tools developer, will take a look at the details.
Jonathan is on vacation now. As he has a long list of todo tasks, I don't
know when he will be able to work on this. We also need to know what
implication the change will have, such as will it work on all platforms?,
any extra work for our maintenance and support?
I can definitely see that the change is an improvement to the tools.
Thanks
--pc
Hi Peter,
attached is a patch to SVN version 18506 of HDF5 1.8 (today) which moves
the "progname" and "d_status" definitions into the tools library
instead of
having them in the main application. This is required for building the
tools
library as dll, since the dll can't reference external symbols defined in
the main application.
Instead I added four new functions to the tools library,
h5tools_setprogname(),
h5tools_getprogname(), h5tools_setstatus(), h5tools_getstatus() which
allow
to communicate those variables with the library.
So far it all compiled and run well under Linux 64, and I could build
h5ls
under Windows with the h5tools library as dll.
I did *not* do an extensive check on other platforms or change anything
in the configure or hdf5 build system. It still builds the tools library
as a static library. Someone else who is more experience with the
autoconf
tool would need to do that, but as far as it concerns the C source code,
those changes should do the job. There might be some undefined symbols
when building the other tools under Windows with a dll, since I didn't
check all of them, but if that happens, it's straightforward to just
add another dll export/import declaration (similar to those at the
h5tools_getprogname() etc. functions).
Werner
On Wed, 10 Mar 2010 14:54:13 -0500, Peter Cao <xcao@hdfgroup.org> wrote:
Werner,
You made a very good suggestion. It is actual in our long-term plan
to make
a set of public tools functions and also to make our current tools more
modular.
Because of other priority, we do not have much resource to commit to the
work.
However, we are working toward to this goal.
As for making some of the current function to be public and build as
dll, you
are welcome to try. If there is no other issue (technical and
non-technical),
we will be happy to include your contribution.
Thanks
--pc
Werner Benger wrote:
This might be a bit too internal for the forum, but maybe still of
interest
for more:
The HDF5 tools (h5dump, h5ls, ...) share common code via the tools
library.
This is currently built as a static library and linked into the main
executables.
It appears it would not be a big effort to modify it to be shared
library/DLL
instead. There are two symbols that from the library are references as
"external"
and are supposed to be defined in the main application. These would
need to go
into the library itself instead to be able to build it as shared
library. Not
a big deal.
If we can have the tools library available through header files and
DLL for
user code as well, it has two advantages: once the executables are a
bit
smaller (which is not really important these days), but secondly one
could
also easier write user-modified versions of h5ls/h5dump etc., for
instance
versions that use another VFD, or output data differently on dump etc.
As a DLL under windows, only addition required in the code were some
symbol export definitions. I'd be volunteering to contribute such.
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
211 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362
Great!!! thanks for the clarification. We will keep you informed on what we can do.
Thanks
--pc
Werner Benger wrote:
···
Hi Peter,
the only platform-dependencies are for the windows-specific dll
import/export definitions, but they are protected by the appropriate #defines already. So no worries to expect here.
The change is actually pretty minimal, so I don't expect it to require
any more maintenance and support rather than remembering that one should
not declare those two symbols progname/d_status in the main application
(if someone writes a new tool) but use the according h5tools_ functions.
One could do more cleanup, since not all tools seem to use the h5tools
library, and also there are functions which pass the progname explicitly
even though it is already known implicitly by the h5tools library, but
I kept any changes to the minimum.
It should also be pretty easy to apply these changes to any further
version if it can't be integrated right now.
Werner
On Fri, 02 Apr 2010 14:18:40 -0400, Peter Cao <xcao@hdfgroup.org> wrote:
Hi Werner,
Thank you very much for your contribution and informing us the
progress of the work. I am glad that it works for you.
Jonathan Kim, our main tools developer, will take a look at the details.
Jonathan is on vacation now. As he has a long list of todo tasks, I don't
know when he will be able to work on this. We also need to know what
implication the change will have, such as will it work on all platforms?,
any extra work for our maintenance and support?
I can definitely see that the change is an improvement to the tools.
Thanks
--pc
Hi Peter,
attached is a patch to SVN version 18506 of HDF5 1.8 (today) which moves
the "progname" and "d_status" definitions into the tools library
instead of
having them in the main application. This is required for building the
tools
library as dll, since the dll can't reference external symbols defined in
the main application.
Instead I added four new functions to the tools library,
h5tools_setprogname(),
h5tools_getprogname(), h5tools_setstatus(), h5tools_getstatus() which
allow
to communicate those variables with the library.
So far it all compiled and run well under Linux 64, and I could build
h5ls
under Windows with the h5tools library as dll.
I did *not* do an extensive check on other platforms or change anything
in the configure or hdf5 build system. It still builds the tools library
as a static library. Someone else who is more experience with the
autoconf
tool would need to do that, but as far as it concerns the C source code,
those changes should do the job. There might be some undefined symbols
when building the other tools under Windows with a dll, since I didn't
check all of them, but if that happens, it's straightforward to just
add another dll export/import declaration (similar to those at the
h5tools_getprogname() etc. functions).
Werner
On Wed, 10 Mar 2010 14:54:13 -0500, Peter Cao <xcao@hdfgroup.org> >>> wrote:
Werner,
You made a very good suggestion. It is actual in our long-term plan
to make
a set of public tools functions and also to make our current tools more
modular.
Because of other priority, we do not have much resource to commit to the
work.
However, we are working toward to this goal.
As for making some of the current function to be public and build as
dll, you
are welcome to try. If there is no other issue (technical and
non-technical),
we will be happy to include your contribution.
Thanks
--pc
Werner Benger wrote:
This might be a bit too internal for the forum, but maybe still of
interest
for more:
The HDF5 tools (h5dump, h5ls, ...) share common code via the tools
library.
This is currently built as a static library and linked into the main
executables.
It appears it would not be a big effort to modify it to be shared
library/DLL
instead. There are two symbols that from the library are references as
"external"
and are supposed to be defined in the main application. These would
need to go
into the library itself instead to be able to build it as shared
library. Not
a big deal.
If we can have the tools library available through header files and
DLL for
user code as well, it has two advantages: once the executables are a
bit
smaller (which is not really important these days), but secondly one
could
also easier write user-modified versions of h5ls/h5dump etc., for
instance
versions that use another VFD, or output data differently on dump etc.
As a DLL under windows, only addition required in the code were some
symbol export definitions. I'd be volunteering to contribute such.
