humanai / gyp

Automatically exported from code.google.com/p/gyp
0 stars 0 forks source link

Shared libraries generated in different locations #57

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The XCode and Visual Studio generators build shared libraries right next to 
the executables (in the configuration directory, e.g. xcodebuild/Debug).

Linux (both Make and SCons) build shared libraries next to the static 
libraries (e.g. in sconsbuild/Debug/lib).  Either make this consistent or 
document it as a difference in how the underlying OS needs to be handled.

Original issue reported on code.google.com by sgk@chromium.org on 7 Aug 2009 at 12:00

GoogleCodeExporter commented 9 years ago

Original comment by sgk@chromium.org on 7 Aug 2009 at 12:00

GoogleCodeExporter commented 9 years ago

Original comment by sgk@chromium.org on 21 Oct 2009 at 5:31

GoogleCodeExporter commented 9 years ago
Issue 74 has been merged into this issue.

Original comment by sgk@chromium.org on 21 Oct 2009 at 5:59

GoogleCodeExporter commented 9 years ago
Would be nice to fix this. I hit this and have to look for workarounds on linux.

Original comment by nirnimesh@chromium.org on 11 May 2010 at 6:31

GoogleCodeExporter commented 9 years ago
I think this is perhaps resolved: shared_library is used internally by gyp so 
other pieces shouldn't rely on their location, while loadable_module writes 
into product_dir.

Original comment by evan@chromium.org on 26 May 2011 at 10:18

GoogleCodeExporter commented 9 years ago
This bug is referenced from ffmpeg.gyp:

          'conditions': [
            ['OS=="linux" or OS=="freebsd" or OS=="openbsd" or OS=="solaris"', {
              'copies': [
                {
                  # On Make and Scons builds, the library does not end up in
                  # the PRODUCT_DIR.
                  #
                  # http://code.google.com/p/gyp/issues/detail?id=57
                  #
                  # TODO(ajwong): Fix gyp, fix the world.
                  'destination': '<(PRODUCT_DIR)',
                  'files': ['<(SHARED_LIB_DIR)/<(SHARED_LIB_PREFIX)ffmpegsumo<(SHARED_LIB_SUFFIX)'],
                },
              ],
            }],
          ],

So maybe it's not fixed?

chrome_dll.gypi has:

              'copies': [
                {
                  'destination':
                      '<(PRODUCT_DIR)/$(CONTENTS_FOLDER_PATH)/Libraries',
                  'files': [
                    # TODO(ajwong): Find a way to share this path with
                    # ffmpeg.gyp so they don't diverge. (BUG=23602)
                    '<(PRODUCT_DIR)/libffmpegsumo.dylib',
                  ],
                },

The xcode generator doesn't define SHARED_LIB_DIR, so there's no xplat way to 
have a "copy shared_library somewhere" step.

Original comment by thakis@chromium.org on 18 Jul 2011 at 4:19

GoogleCodeExporter commented 9 years ago
I think I was thinking that shared_library isn't used anywhere anymore, but I 
admit I am fuzzy on how frameworks work in Mac Chrome.

Original comment by evan@chromium.org on 18 Jul 2011 at 5:09