Вск Янв 26 16:16:51 2020, PLICEASE писал:
Show quoted text> On Sun Jan 26 05:02:09 2020, SYBER wrote:
> > - shared library is built, so all dependencies shares the same
> > library
>
> Interesting. It seems as though you are trying to do something
> similar to Module::CAPIMaker. It might be worth while spending some
> time collaborating or at least coordinating with the author of that
> module (or the tool chain folks) to avoid duplication or
> incompatibilities.
Now exactly similar. XS::Install provides way more features. With Module::CAPIMaker i have to write additional strange file with C API (a copy-paste of methods definitions that are externally visible), while XS::Install works like native C infrastructure (it installs all needed header files). It is especially important when writing in C++.
XS::Install also automatically propagates all CCFLAGS/ LIBS etc to children
Show quoted text>
> This approach means that your Alien becomes a run-time requirement.
> (Aliens typically are build-only prereqs for XS modules).
Yes. But i don't see anything bad about it. It saves disk space and memory. Because with static library concept, it will be inside multiple XS modules that use it and it will load to memory several times.
Show quoted text> It also
> means that installing an upgraded to one of your Aliens with a
> breaking API change will break all of the XS modules that are
> depending on it.
Almost all of CPAN XS modules has very simple architecture. They are black boxes that only interact with perl.
Our modules uses another approach.
For example there is URI::XS and Date fast frameworks. On one hand they expose their functionality to perl as usual. On the other hand, Unievent::HTTP (not yet on cpan) uses them both in it's API and receive those objects to its functions (URI::XS and Date has "xs/uri.h" and "xs/date.h" which exposes shared typemaps for other XS modules).
for example
my $uri = URI:XS->new("....."); # a C++ object hidden behind perl's magic
my $request = UniEvent::HTTP::Request->new(
...
uri => $uri,
...
);
XS function UniEvent::HTTP::Request::new receives uri as C++ object via typemaps
auto uri = xs::in<URI*>(sv);
UE::HTTP works with C++ framework URI directly and therefore has no penalty on perl-C-perl interaction. This approach is very important for achieving extremely high speeds.
For example it is hundred times faster than Starman and even faster than plain NGINX.
and the same for UniEvent::WebSocket and so on.
XS::Install and XS::Framework together has a huge support for building such architectures. And it is a superset, more general and more C-native way than Module::CAPIMaker offers.
So as you share the same objects between different XS modules, they HAVE to use shared libraries. To protect yourself from various hard-to-debug SIGSEGVs caused by updating some parent to a new version, there is a binary compability protection feature (see below).
Show quoted text>
> I can see some advantages for this approach, but I do think it should
> be decoupled from the Alien concept. Something like Module::CAPIMaker
> or XS::Install could use an existing Alien to create an XS with
> dependencies, instead of trying to reproduce what the Alien
> infrastructure that already exists. A fair amount of thought and
> experience has gone into creating these tools.
We could in theory use Alien::libuv to create module, but only for something like Alien::uv ))
Because C objects created in one XS module can easily be passed to another XS module, it is required that libuv is shared library.
For example consider 2 XS modules
Libuv::Adapter (exposes libuv interface to perl)
Libuv::Plugin (some addon that does something to libuv objects)
Because both are built against libuv, and objects created in Libuv::Adapter are passed to Libuv::Plugin, libuv has to be a shared library. Otherwise binary incompability would occur if they are built again different versions of libuv
So we anyway need something like Alien::uv that builds and make available libuv.so
Show quoted text>
> As an example, I noticed that Alien::uv, unlike the normal practice of
> Aliens, does not attempt to use the system libuv.
Yes this is a must-have feature, that we didn't implement yet. I planned to add it soon.
If you want to expel us from Alien::* namespace we could of course move to another namespace. But i chose Alien:: namespace because it logically seems ok (it provides access to external library)
Show quoted text> This can be a
> problem for system integrators (like Debian or Fedora), should they
> want to create packages of your downstream modules.
>
> > - you dont need to pass various flags (ccflags, libs, etc) by hand.
>
> This is also not necessary with Alien::Base::Wrapper, which works with
> existing installer ExtUtils::MakeMaker and Module::Build. The Alien-
> Build infrastructure also works well with other technologies like
> Inline::C and FFI. Frankly it is sometimes useful to be able to get
> the cflags and libs from an Alien.
>
> > - automatic binary incompability protection.
>
> After reviewing the XS::Install documentation, I am not exactly sure
> what you mean by this.
I'll explain with example:
i installed Alien::uv version 1.28
then i installed libuv::adapter
everything's ok.
and then i update Alien::uv to 1.29
while doing this i'll get a warning:
******************************************************************************
XS::Install: There are XS modules that binary depend on current XS module Alien::uv.
They were built with currently installed Alien::uv version 1.28.0.5.
If you install Alien::uv version 1.29.0.5, you will have to reinstall all XS modules that binary depend on it:
cpanm -f Panda::W Panda::X Panda::X::Front UniEvent UniEvent::HTTP UniEvent::Socks UniEvent::WebSocket
******************************************************************************
(Unfortunately i haven't found any API in CPAN that would make that "rebuild" occur automatically)
And even if i ignore that warning and try to run my software after upgrading Alien::libuv and not rebuilding libuv::adapter,
i'll get on startup:
DB<1> use UniEvent
******************************************************************************
XS::Loader: XS module UniEvent binary depends on XS module Alien::uv.
UniEvent was compiled with Alien::uv version 1.28.0.5, but current version is 1.29.0.5.
Please reinstall all modules that binary depend on Alien::uv:
cpanm -f Panda::W Panda::X Panda::X::Front UniEvent UniEvent::HTTP UniEvent::Socks UniEvent::WebSocket
******************************************************************************
Compilation failed in require at (eval 13)[/home/syber/perl5/perlbrew/perls/5.30.0dm/lib/5.30.0/perl5db.pl:738] line 2.
Show quoted text>
> I think what you are trying to do is useful and has value, but working
> with the developers of the existing related technology on CPAN will
> improve the chances of your tools being useful.
