[NaCl SDK] Add nacl_mounts to NaCl SDK build. Experimental for now.

[NaCl SDK] Add nacl_mounts to NaCl SDK build. Experimental for now.

Also add --experimental flag to build_sdk.py so we can test a library without
it being included in the archived SDK.

BUG=122229
TEST=none
R=noelallen@chromium.org
NOTRY=true


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=149372

[binji, 2012-07-26 22:49:58]

http://codereview.chromium.org/10829027/diff/4001/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_mounts/library.dsc (right):

http://codereview.chromium.org/10829027/diff/4001/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_mounts/library.dsc:45: 'FILES': [
I'll refactor this out in the next CL

http://codereview.chromium.org/10829027/diff/4001/native_client_sdk/src/libra...
File native_client_sdk/src/libraries/nacl_mounts/mount.h (right):

http://codereview.chromium.org/10829027/diff/4001/native_client_sdk/src/libra...
native_client_sdk/src/libraries/nacl_mounts/mount.h:87: Mount* mnt = new C();
gcc complained that Mount was used before it was defined.

[noelallen1, 2012-07-27 00:29:40]

LGTM however...

I'm not sure that NaCl Mounts is the only use case for dirents, and other POSIX
functions.  I'm not convinced moving them to NaCl Mounts is the right place, and
instead, if we should provide include/win/dirents.h.

Also, idirafter prevents us from "stealing" fopen, open, etc...

Again, if this works on Windows for both Pepper and NaCl, then I think we have
most of our bases covered.  But keep in mind we will need to steal 'open' on
POSIX systems without resorting to the special library override via IRT stuff
available in NaCl.

https://chromiumcodereview.appspot.com/10829027/diff/4001/native_client_sdk/s...
File native_client_sdk/src/build_tools/build_sdk.py (right):

https://chromiumcodereview.appspot.com/10829027/diff/4001/native_client_sdk/s...
native_client_sdk/src/build_tools/build_sdk.py:431: 'nacl_mounts',
The LIBRARY_LIST specifies the build order.  Since libraries don't currently
include libraries I think this is okay....

https://chromiumcodereview.appspot.com/10829027/diff/4001/native_client_sdk/s...
native_client_sdk/src/build_tools/build_sdk.py:547:
#buildbot_common.Run(['make', '-j8'],
Is this a left over?  Or do you want to keep it to make the logs more sane?

[binji, 2012-07-27 03:43:11]

I see what you're saying about dirent.h, etc. I only wanted to implement the
minimal amount needed for nacl_mounts, but I can see why having a fuller
implementation in include/win would be useful.

BTW, they aren't moved exactly, it's just that VS2008 doesn't have stdint.h,
dirent.h, ssize_t, mode_t, etc. I thought it was a little nicer to include an
"os<whatever>.h" which would include the necessary stuff.

idirafter: if we use -I$(NACL_SDK_ROOT)/include it seems that #include
<ppapi/...> will use this directory instead of the headers in toolchain. Is that
what we want? I think it would be weird to be working on a project without
nacl_mounts, have it work one way, then add the nacl_mounts includes and
suddenly get (potentially) different behavior.

stealing open, dup, etc: Is that right? I thought we were just overriding
symbols... the developer will still use #include <stdio.h> or whatever, we just
take over what open actually does. (naclports examples seem to be using
-Wl,-wrap,open to do this. Do we have a different way?)

[binji, 2012-07-27 18:16:39]

http://codereview.chromium.org/10829027/diff/4001/native_client_sdk/src/build...
File native_client_sdk/src/build_tools/build_sdk.py (right):

http://codereview.chromium.org/10829027/diff/4001/native_client_sdk/src/build...
native_client_sdk/src/build_tools/build_sdk.py:431: 'nacl_mounts',
On 2012/07/27 00:29:40, noelallen1 wrote:
> The LIBRARY_LIST specifies the build order.  Since libraries don't currently
> include libraries I think this is okay....

Ah, I see now. I thought it just looked nicer sorted ... :-)
Well, if/when I add a util library it will need to precede nacl_mounts.

http://codereview.chromium.org/10829027/diff/4001/native_client_sdk/src/build...
native_client_sdk/src/build_tools/build_sdk.py:547:
#buildbot_common.Run(['make', '-j8'],
On 2012/07/27 00:29:40, noelallen1 wrote:
> Is this a left over?  Or do you want to keep it to make the logs more sane?

Whoops, left over. I was using it to make it easier to catch build errors.

[binji, 2012-07-27 19:25:35]

On 2012/07/27 03:43:11, binji wrote:
> I see what you're saying about dirent.h, etc. I only wanted to implement the
> minimal amount needed for nacl_mounts, but I can see why having a fuller
> implementation in include/win would be useful.
> 
> BTW, they aren't moved exactly, it's just that VS2008 doesn't have stdint.h,
> dirent.h, ssize_t, mode_t, etc. I thought it was a little nicer to include an
> "os<whatever>.h" which would include the necessary stuff.
OK, I missed that you already added dirent.h and stdint.h to libraries/win... :)

> 
> idirafter: if we use -I$(NACL_SDK_ROOT)/include it seems that #include
> <ppapi/...> will use this directory instead of the headers in toolchain. Is
that
> what we want? I think it would be weird to be working on a project without
> nacl_mounts, have it work one way, then add the nacl_mounts includes and
> suddenly get (potentially) different behavior.
> 
> stealing open, dup, etc: Is that right? I thought we were just overriding
> symbols... the developer will still use #include <stdio.h> or whatever, we
just
> take over what open actually does. (naclports examples seem to be using
> -Wl,-wrap,open to do this. Do we have a different way?)

[commit-bot: I haz the power, 2012-08-01 04:08:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/binji@chromium.org/10829027/10001

[commit-bot: I haz the power, 2012-08-01 04:08:33]

Failed to apply patch for native_client_sdk/src/build_tools/make_rules.py:
While running patch -p1 --forward --force;
patching file native_client_sdk/src/build_tools/make_rules.py
Hunk #3 FAILED at 33.
1 out of 8 hunks FAILED -- saving rejects to file
native_client_sdk/src/build_tools/make_rules.py.rej

[commit-bot: I haz the power, 2012-08-01 04:35:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/binji@chromium.org/10829027/15003

[commit-bot: I haz the power, 2012-08-01 04:36:22]

Change committed as 149372