xmlstar-devel

[Xmlstar-devel] XMLStarlet 1.0.3 released

[Noam P. <npo...@us...>]

Hi list,

I just released version 1.0.3

   - Bug fixes:
      escape --value in update mode (Bug 3052978)
      c14n now includes default attributes (Bug 1505579)
      Allow special characters in sel --output literal (Bug 1912978)
      remove warning from xml_trans.c (Bug 1521756)
      Use xmlReader interface so line numbers are 32-bit (Bug 1219072)
      test for error messages on lines past 2^16 (Bug 1219072)
      don't look for embedded dtd if not asked (Bug 1167215)

Noam

Re: [Xmlstar-devel] XMLStarlet 1.0.3 released

[André K. <ak...@la...>]

> I just released version 1.0.3
>
> - Bug fixes:
>    escape --value in update mode (Bug 3052978)
>    c14n now includes default attributes (Bug 1505579)
>    Allow special characters in sel --output literal (Bug 1912978)
>    remove warning from xml_trans.c (Bug 1521756)
>    Use xmlReader interface so line numbers are 32-bit (Bug 1219072)
>    test for error messages on lines past 2^16 (Bug 1219072)
>    don't look for embedded dtd if not asked (Bug 1167215)
>

Congratulation!
I created a branch to put my "enhanced" version of xml_select.c.
I'm currently unable to regenerate a working configure file from the  
updated autotools scripts.
I'm on MacOSX.

Could you provide me some hints on how to regenerate them?
I assumed
$ NOCONFIGURE=1 ./autogen.sh
would be sufficient.

I'm currently having
./configure: line 2754: syntax error near unexpected token `LIBXML,'
./configure: line 2754: `XSTAR_LIB_ARGS_WITH(LIBXML, with-src)'

Regards,
André

Re: [Xmlstar-devel] XMLStarlet 1.0.3 released

[André K. <ak...@la...>]

>
> Sorry about that, I should have removed autogen.sh, just use
> $ autoreconf -si
>

No problem, I was focusing on my branch and getting to know git.
But this looks nicer with autoreconf.
Is there a reason with xmlstarlet is linked statically?

Regards,
André

Re: [Xmlstar-devel] XMLStarlet 1.0.3 released

[Noam P. <npo...@us...>]

On Sat, Nov 20, 2010 at 6:55 PM, André Kaplan <ak...@la...> wrote:
> Is there a reason with xmlstarlet is linked statically?
>
> Regards,
> André

According to
http://sourceforge.net/tracker/index.php?func=detail&aid=820996&group_id=66612&atid=515109

> I'm not planning to support linking with shared libraries.
> I think having it statically liked make it self contained,
> and easier
> to handle for a user.
> It also helps to avoid incomatibility problems in cases when
> shared libraries are upgraded. Binaries which are released
> pass regression testing with particular version of libxml2
> and libxslt.

> Thanks
> --MG

Although given that distro (eg Debian's, probably others') packages
link with shared libraries,
perhaps insisting on static linking isn't worthwhile.

Noam

Re: [Xmlstar-devel] XMLStarlet 1.0.3 released

[André K. <ak...@la...>]

> On Sat, Nov 20, 2010 at 6:55 PM, André Kaplan <ak...@la...>  
> wrote:
>> Is there a reason with xmlstarlet is linked statically?
>>
>> Regards,
>> André
>
> According to
> http://sourceforge.net/tracker/index.php?func=detail&aid=820996&group_id=66612&atid=515109
>
>> I'm not planning to support linking with shared libraries.
>> I think having it statically liked make it self contained,
>> and easier
>> to handle for a user.
>> It also helps to avoid incomatibility problems in cases when
>> shared libraries are upgraded. Binaries which are released
>> pass regression testing with particular version of libxml2
>> and libxslt.
>
>> Thanks
>> --MG
>
> Although given that distro (eg Debian's, probably others') packages
> link with shared libraries,
> perhaps insisting on static linking isn't worthwhile.

While I understand the need for static linking under certain  
circumstances, I'd actually prefer to make a choice.
I think I've seen --enable-static options in configure.
I'd really appreciate it for xmlstarlet.

Regards,
André

Re: [Xmlstar-devel] XMLStarlet 1.0.3 released

[Noam P. <npo...@us...>]

"Weddington, Eric" <Eri...@at...> writes:

>> -----Original Message-----
>> From: Noam Postavsky [mailto:npo...@us...]
[...]
>> Although given that distro (eg Debian's, probably others') packages
>> link with shared libraries,
>> perhaps insisting on static linking isn't worthwhile.
>> 
>
>
> Note that static linking is preferred when building for Windows
> (host=mingw). It makes it easier to redistribute.

Well yes, what I meant was it's not worth the trouble of putting code in
configure to compute /path/to/libxml.a, when -lxml would work fine. When
building the Windows release I didn't build the shared libraries so
using -lxml there would link with libxml.a anyways.

Noam