Distribute mxml along with ADIOS, or make it optional #8
Comments
|
If mxml is as small as you say, why can't you install it yourself? Actually, what OS are you using that it's not available? It seems fairly old. Anyway, when I asked them about it before, they said you can ignore mxml if you don't install the write interface ( |
|
Just wondering are you a developer of ADIOS? The general response to your questions is that I need MXML either included, if it is going to be a requirement, or need it removed as a requirement. I will either do this myself, or if one of the existing developers at ORNL is willing to do so, then even better.
As I described in my original post: "This would be one less step in getting ADIOS set up and installed." Of course I can install it myself, I would just rather not have to. If every single library sets off a chain reaction of dependencies the build procedure for a code rapidly becomes very complex. This isn't a problem for me personally, but my code has many users for who just building a single code is already a significant challenge, and inevitably leads to a large number of support requests which consumes a significant amount of my time.
Various linux and mac systems. Pretty much anything I have to run on, it's not installed by default. All of these systems I do not have admin privileges on, so it is unlikely to be installed system-wide.. As a result, users of my code, which optionally uses ADIOS, not only have to install ADIOS, they have to install MXML. Many of these users have trouble building one code, let alone getting a chain of dependencies working together correctly.
That's not an option. Of course, I need the write interface. |
No, I am speaking as a fellow package maintainer. Bundling dependencies is troublesome. Dependency tracking is a distribution's specialty after all. Is it more trouble than it's worth? I don't know, that's up to the ADIOS developers to decide. I'm just pointing out that there may be other costs: keeping it updated, security fixes, build patches, integrating it with your existing build, etc. It's unfortunate that much scientific software is not packaged, because distributors have solved these problems many times over.
Ah, everywhere I've had to use it, it's existed. I was more interested in which systems didn't have mxml packaged, but without admin privileges, maybe that's irrelevant. |
|
This seems to be an old issue but I'd like to revisit it. In particular, we're using both the read and write API but only the no-XML interfaces, so just disabling the write interface isn't really an option. While I definitely wouldn't say I'm one of the ADIOS developers, I have been making the occasional patch. I'm going to try to look into separating out the XML dependency and try to get a branch out in the next week or two. |
|
I am an user on Titan, Rhea and EOS@ORNL. I experienced several times when mxml is not configured correctly in adios on ORNL machines. So I basically load the adios and mxml from the system modules but there are still times things didn't work. Just today, I am working on python APIs one EOS@ORNL, and when I import the adios, it told me it can't find I know from the software developer's point, mxml should be independently built but there are just times things get broken. My two cents... |
|
mxml is packaged into ADIOS since 1.10 |
Is it possible to distribute and automatically build MXML with ADIOS? I wouldn't make such a request about a large library like HDF5, but MXML is small and not that common either. This would be one less step in getting ADIOS set up and installed.
Alternatively, could the XML interface to ADIOS please be made optional? My code doesn't use the XML interface to ADIOS, so perhaps it is not necessary, and could be disabled at compile-time.
The text was updated successfully, but these errors were encountered: