The changes are already in the upstream (and in the last release of BLIS),
so maintaining the source repository is not an issue.

My concern is about ease-of-use for other users. Getting through build docs
and manually managing the paths might be a high burden for new users,
especially the ones who don't have previous experience with native
development. The difficulty of using libraries, in turn, is a big
disincentive for library devs to provide an Emscripten port. And without a
collection of easy-to-use libraries Emscripten would not get as wide
adaption as it deserves.

What I'd like to have is an Emscripten's analog of naclports project (which
contains ports of different packages for Native Client technology). It is
fine if, at least initially, only open source packages would be accepted,
and they would need to rebuild with every toolchain update (this is how
naclports currently works). If a package manager would provide a universal
way to build and install packages, it would be of great benefit for both
Emscripten ecosystem and OSS libraries.

Regards,
Marat


On Tue, Jul 29, 2014 at 12:19 AM, Jukka Jylänki <[email protected]> wrote:

> The ultimately preferable route would be to get your changes to the
> upstream BLIS repository, so people who clone the trunk from them would be
> Emscripten-ready immediately, and would have the same workflow of obtaining
> the source as with other platforms. If that's not practical, then we have
> typically maintained our own fork at github, e.g.
> https://github.com/juj/emscripten-freetype or
> https://github.com/gsathya/SDL-emscripten .
>
> There's a plan of adding external library downloads to emsdk, since it
> already implements package manager functionality, but that hasn't yet been
> implemented. Also notable is that we don't currently have a strong
> cross-compiler-version support story for precompiled binaries in
> Emscripten, and if you e.g. compiled a library with 1.21.0, and migrated to
> 1.21.1, you should recompile the code fully from sources after updating, so
> packaging up precompiled versions is generally not very useful.
>
> Perhaps having a BLIS-emscripten repository or similar with
> Emscripten-specific build README.md would be a good path?
>
>
> 2014-07-29 9:13 GMT+03:00 Marat Dukhan <[email protected]>:
>
>> Hi,
>>
>> I've ported BLIS library <https://github.com/flame/blis> for linear
>> algebra operations to Emscripten, and would like to make it easy to use for
>> other Emscripten users.
>> What are the best practices for library packaging and package
>> distribution for Emscripten?
>>
>> I've seen empkg project a while ago, but it doesn't seem to be maintained
>> anymore.
>>
>> Regards,
>> Marat
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "emscripten-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "emscripten-discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/emscripten-discuss/jxlbkvWGIoE/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to