Applications to NaCl port central
12 views
Skip to first unread message
peterretief
Nov 23, 2009, 5:28:42 AM11/23/09
to Native Client Discuss
Hi
Is there a repository of applications ported to NaCl?
Regards
Peter
Is there a repository of applications ported to NaCl?
Regards
Peter
centipede
Nov 26, 2009, 6:22:28 AM11/26/09
to Native Client Discuss
> Is there a repository of applications ported to NaCl?
Not that I know of. It would be nice to have, I agree.
And throw in a subsection for requests so developers can get a few
ideas for porting as well.
Cheers,
Rene
Brad Chen
Nov 26, 2009, 10:23:50 AM11/26/09
to native-cli...@googlegroups.com
The native_client/tests directory has some examples of what we've done ourselves. We are working on a better structure for sharing of ported libraries and contributed applications. Feedback and suggestions on this topic are very welcome.
Brad
-- You received this message because you are subscribed to the Google Groups "Native Client Discus...
centipede
Nov 26, 2009, 12:47:13 PM11/26/09
to Native Client Discuss
Hi Chen!
A few notes that you probably already have considered (so let them
count as "opinions").
Help both C++ developers and web developers:
The C++ people need a place to share libraries that have succesfully
been ported and an area where we can discuss common tips and specific
solutions (e.g. dealing with autoconf). I guess that each such project
could be hosted on Google Code. The main issue is that a lot of
projects need many libraries. So some sort of "package" system
allowing us to simply install e.g. "pkg-config" or "libpng" rather
than each person having to recompile them all on their own. It would
imho speed up development and motivate quite a bit.
I've looked at the latest Nacl download, and while I understand that
the focus right now is to fit NaCl into Chrome, it also becomes less
and less transparent what to do as a non-initiated C++ developer.
Nokia has a good well-worked procedure for newcomers wanting to port
to Maemo: A complete environment only for cross compiling.
Use the scons/python/gclient build systems for building nacl itself.
*Don't* use it for building examples and ports. Instead tell us how to
make a jail inside which we can assure that autoconf/gcc etc. will
*not* find our normal x86 libraries and header files and use them. I'm
at the point where simply finding the nacl-sdk folder and copying bin/
lib/include etc. into a separate area and modify environment variables
like CC, CFLAGS... is the simplest way to get started (-nostdinc is a
good gcc flag by the way).
The web folks are probably only interested in finished .nexe programs
which have been designed for web use in particular. I would love a
gallery of widgets where I could preview each widget, see what
JavaScript code was needed and have a chance to discuss/request
features.
Once again, if we examine Maemo, it becomes clear that porting is not
enough. Things work differently, both on a handheld and in the NaCl
space, so some amount of recoding is always needed.
Perhaps the best thing would be a place where users, webdevelopers and
c++developers could help each other by discussing what is missing (the
users' contribution), how it could be solved properly as a web
application (the web developers' contribution) and how it could be
built using existing C++ code (the contributions from the C++ guys).
Such an approach could potentially even reduce the amount of people
all trying to port the same library since we had a central hub where
people synchronized their work.
Another thing: You people at Google are obviously playing a key role
in the roadmap of NaCl. It is up to *you* to coordinate the first
steps of a coming community: Almost all porting projects will hit the
same walls, i.e. how to deal with missing file support, missing dlopen
support, network and many other things. Solving these on a high level
each time is simply not a good way to exploit the limited human
resources involved.
Personally I think you should lead on in coding a faked libc and
whatever other library could be needed.
Okay, that's a few responses on things so far. I've seen a few
exciting comments in the Chromium project (an OpenGL test example was
one of them, yep, we didn't miss that one). Do keep us updated,
thanks. Especially about schedules and roadmaps.
Cheers,
Rene Jensen
On Nov 26, 4:23 pm, Brad Chen <bradc...@google.com> wrote:
> The native_client/tests directory has some examples of what we've done
> ourselves. We are working on a better structure for sharing of ported
> libraries and contributed applications. Feedback and suggestions on this
> topic are very welcome.
>
> Brad
>
A few notes that you probably already have considered (so let them
count as "opinions").
Help both C++ developers and web developers:
The C++ people need a place to share libraries that have succesfully
been ported and an area where we can discuss common tips and specific
solutions (e.g. dealing with autoconf). I guess that each such project
could be hosted on Google Code. The main issue is that a lot of
projects need many libraries. So some sort of "package" system
allowing us to simply install e.g. "pkg-config" or "libpng" rather
than each person having to recompile them all on their own. It would
imho speed up development and motivate quite a bit.
I've looked at the latest Nacl download, and while I understand that
the focus right now is to fit NaCl into Chrome, it also becomes less
and less transparent what to do as a non-initiated C++ developer.
Nokia has a good well-worked procedure for newcomers wanting to port
to Maemo: A complete environment only for cross compiling.
Use the scons/python/gclient build systems for building nacl itself.
*Don't* use it for building examples and ports. Instead tell us how to
make a jail inside which we can assure that autoconf/gcc etc. will
*not* find our normal x86 libraries and header files and use them. I'm
at the point where simply finding the nacl-sdk folder and copying bin/
lib/include etc. into a separate area and modify environment variables
like CC, CFLAGS... is the simplest way to get started (-nostdinc is a
good gcc flag by the way).
The web folks are probably only interested in finished .nexe programs
which have been designed for web use in particular. I would love a
gallery of widgets where I could preview each widget, see what
JavaScript code was needed and have a chance to discuss/request
features.
Once again, if we examine Maemo, it becomes clear that porting is not
enough. Things work differently, both on a handheld and in the NaCl
space, so some amount of recoding is always needed.
Perhaps the best thing would be a place where users, webdevelopers and
c++developers could help each other by discussing what is missing (the
users' contribution), how it could be solved properly as a web
application (the web developers' contribution) and how it could be
built using existing C++ code (the contributions from the C++ guys).
Such an approach could potentially even reduce the amount of people
all trying to port the same library since we had a central hub where
people synchronized their work.
Another thing: You people at Google are obviously playing a key role
in the roadmap of NaCl. It is up to *you* to coordinate the first
steps of a coming community: Almost all porting projects will hit the
same walls, i.e. how to deal with missing file support, missing dlopen
support, network and many other things. Solving these on a high level
each time is simply not a good way to exploit the limited human
resources involved.
Personally I think you should lead on in coding a faked libc and
whatever other library could be needed.
Okay, that's a few responses on things so far. I've seen a few
exciting comments in the Chromium project (an OpenGL test example was
one of them, yep, we didn't miss that one). Do keep us updated,
thanks. Especially about schedules and roadmaps.
Cheers,
Rene Jensen
On Nov 26, 4:23 pm, Brad Chen <bradc...@google.com> wrote:
> The native_client/tests directory has some examples of what we've done
> ourselves. We are working on a better structure for sharing of ported
> libraries and contributed applications. Feedback and suggestions on this
> topic are very welcome.
>
> Brad
>
Reply all
Reply to author
Forward
0 new messages