Add native extensions for the Dart shell to the MacOs platform

Add native extensions for the Dart shell to the MacOs platform


BUG=
TEST=

This CL is superceded by https://chromiumcodereview.appspot.com/9465004/,
and so is closed without committing.

[Bill Hesse, 2012-03-05 17:21:36]

I found out the gyp settings to make the project build (the command line file
was just a note, and will be removed):
type = loadable_module

'xcode_settings': {
 'OTHER_LDFLAGS': [ '-undefined', 'dynamic_lookup' ],

So I'll put those in the gypi file, and it works great - will upload those
changes.

[Søren Gjesse, 2012-03-05 20:55:19]

lgtm

[Ivan Posva, 2012-03-05 23:07:47]

Please refrain from committing this. Apart from the fact that combining Linux
and Mac OS X is a bad idea, we also feel that the abstractions you are exposing
here are wrong. The fact that you need a OS-specific test should tell you that
there is something wrong with your APIs.

Thanks,
-Ivan

https://chromiumcodereview.appspot.com/9599014/diff/1/runtime/bin/extensions_...
File runtime/bin/extensions_posix.cc (right):

https://chromiumcodereview.appspot.com/9599014/diff/1/runtime/bin/extensions_...
runtime/bin/extensions_posix.cc:24: const int buffer_length =
strlen(library_name) + strlen("./lib.so") + 1;
Please do not share Linux and Mac OS X code. There is a huge urge to make them
common until you realize it does not work. Prime example here: Shared libraries
on Mac OS X do not end with .so. Siva and I have been down that path many times
and we did decide on OS-specific files for a reason.

[Mads Ager (google), 2012-03-06 07:33:48]

There should be only one test-extension.cc file. As far as I can tell, the only
thing that could be platform specific is the macro for exporting symbols.

I would be fine with splitting out the extension code per platform.

[Mads Ager (google), 2012-03-06 07:39:50]

https://chromiumcodereview.appspot.com/9599014/diff/1/runtime/bin/bin.gypi
File runtime/bin/bin.gypi (right):

https://chromiumcodereview.appspot.com/9599014/diff/1/runtime/bin/bin.gypi#ne...
runtime/bin/bin.gypi:433: 'test_extension_posix.cc',
This should just be test_extension.cc and everything needed to build it should
be included here. All the special flags for the different platforms.

https://chromiumcodereview.appspot.com/9599014/diff/1/runtime/macos_compile_e...
File runtime/macos_compile_extension_command.txt (right):

https://chromiumcodereview.appspot.com/9599014/diff/1/runtime/macos_compile_e...
runtime/macos_compile_extension_command.txt:2: /Developer/usr/bin/g++-4.2 -arch
i386 -bundle -undefined dynamic_lookup -isysroot /Developer/SDKs/MacOSX10.5.sdk
-L/Users/whesse/trunk/dart/runtime/xcodebuild/Debug_ia32
-F/Users/whesse/trunk/dart/runtime/xcodebuild/Debug_ia32 -filelist
/Users/whesse/trunk/dart/runtime/xcodebuild/dart-runtime.build/Debug_ia32/test_extension.build/Objects-normal/i386/test_extension.LinkFileList
-mmacosx-version-min=10.5 -single_module -o
/Users/whesse/trunk/dart/runtime/xcodebuild/Debug_ia32/libtest_extension.so
We need to get rid of this and integrate the building of the test_extension
correctly in the gyp files.

[Bill Hesse, 2012-03-06 17:18:24]

All comments addressed.  The posix files are split into linux and macos files,
even when they are identical.

Gyp builds loadable bundles with the .so extension, but if you insist, we can
rename the output to a .bundle extension.  That is included in the
extensions_macos.cc file.  The option is not yet in the gypi file.

The test_extension files are identical, and are merged in the separate CL for
the windows change.  There is no OS specific test.  Please explain what is wrong
with the API.

The build command is now incorporated in the gyp build, and the file will be
deleted.

[siva, 2012-03-07 00:14:49]

https://chromiumcodereview.appspot.com/9599014/diff/3002/runtime/bin/extensio...
File runtime/bin/extensions_macos.cc (right):

https://chromiumcodereview.appspot.com/9599014/diff/3002/runtime/bin/extensio...
runtime/bin/extensions_macos.cc:44: return (*fn)(parent_library);
The API could be factored as:

void* Extensions::LoadLibrary(const char* extension_name);
void* Extensions::ResolveSymbol(void* library_handle, const char* name, char**
error);

Then only the implementation of these functions would be platform specific and
the rest of the code could be in a generic file.