Distribute mxml along with ADIOS, or make it optional about adios HOT 6 CLOSED

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 (--disable-write).

from adios.

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.

If mxml is as small as you say, why can't you install it yourself?

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.

Actually, what OS are you using that it's not available?

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.

Anyway, when I asked them about it before, they said you can ignore mxml if you don't install the write interface (--disable-write).

That's not an option. Of course, I need the write interface.

from adios.

Just wondering are you a developer of ADIOS?

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.

Various linux and mac systems. Pretty much anything I have to run on, it's not installed by default.

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.

from adios.

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.

from adios.

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 libmxml.so.

I know from the software developer's point, mxml should be independently built but there are just times things get broken.

My two cents...

from adios.

mxml is packaged into ADIOS since 1.10

from adios.