xrootd build requires:: libxml2 vs tinyxml

[adriansev]

I noticed that there are 2 xml requirements: lixml2 and tinyxml.
Are these 2 both needed? is tinyxml supposed to supersede libxml2?
Thanks a lot for any clarification!

[xrootd-dev]

Actually it's more complicated than that. Originally we simply used our own version of tinyxml (see xrootd/src/XrdXml/tinyxml) and there were no explicit dependencies; though we allowed sites to optionally use libxml2 just in case there was a problem with our version of tinyxml. Then we ran into an EPEL rule that says that we cannot do that if a site has installed tinyxml and if it has then we are supposed to use the installed version. So, somewhere in that whole process these additional requirements were imposed but I don't know the history behind that. So, the answer is in reality there need not be any requirements but the distrib bureacracy says otherwise.

…

On Tue, 21 Feb 2023, Adrian Sevcenco wrote: I noticed that there are 2 xml requirements: lixml2 and tinyxml. Are these 2 both needed? is tinyxml supposed to supersede libxml2? Thanks a lot for any clarification! -- Reply to this email directly or view it on GitHub: #1924 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1

[adriansev]

Actually it's more complicated than that. Originally we simply used our own version of tinyxml (see xrootd/src/XrdXml/tinyxml) and there were no explicit dependencies; though we allowed sites to optionally use libxml2 just in case there was a problem with our version of tinyxml. Then we ran into an EPEL rule that says that we cannot do that if a site has installed tinyxml and if it has then we are supposed to use the installed version. So, somewhere in that whole process these additional requirements were imposed but I don't know the history behind that. So, the answer is in reality there need not be any requirements but the distrib bureacracy says otherwise.

so.. would that mean that tintxml is redundant and the only (prefered) requirement is libxml2?
maybe this could use some clean up? i see in src/XrdXml/XrdXmlReader.cc:50 that if libxml2 is present it will always be used but the cmake configuration allows both to be present (and linked against?) which could be messy..

So, would be possible to make them exclusive? (as a first step)
Then, given that both are widely distributed, maybe just use only one of them?
Thanks a lot!

[abh3]

So, we has a discussion about this. Right now we are looking to see if we can drop both requirements and use the builtin code, possibly renamed to avoid rule conflicts. Right now I believe it will use the tinyxml version as that's the default.

On Wed, 22 Feb 2023, Adrian Sevcenco wrote: > Actually it's more complicated than that. Originally we simply used our own version of tinyxml (see xrootd/src/XrdXml/tinyxml) and there were no explicit dependencies; though we allowed sites to optionally use libxml2 just in case there was a problem with our version of tinyxml. Then we ran into an EPEL rule that says that we cannot do that if a site has installed tinyxml and if it has then we are supposed to use the installed version. So, somewhere in that whole process these additional requirements were imposed but I don't know the history behind that. So, the answer is in reality there need not be any requirements but the distrib bureacracy says otherwise. so.. would that mean that tintxml is redundant and the only (prefered) requirement is libxml2? maybe this could use some clean up? i see in src/XrdXml/XrdXmlReader.cc:50 that if

libxml2 is present it will always be used but the cmake configuration allows both to be present (and linked against?) which could be messy..

…

So, would be possible to make them exclusive? (as a first step) Then, given that both are widely distributed, maybe just use only one of them? Thanks a lot! -- Reply to this email directly or view it on GitHub: #1924 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[abh3]

Working now successfully as designed.