emscripten/emar

#!/usr/bin/env python2

'''
emar - ar helper script
=======================

This script acts as a frontend replacement for ar. See emcc.
'''

import os, subprocess, sys
from tools import shared

DEBUG = os.environ.get('EMCC_DEBUG')
if DEBUG == "0":
   DEBUG = None

newargs = [shared.LLVM_AR] + sys.argv[1:]

if DEBUG:
  print >> sys.stderr, 'emar:', sys.argv, '  ==>  ', newargs

if len(newargs) > 2:
  subprocess.call(newargs)
Updated scripts to call python2 directly rather than relying on python symlink pointing to the right place. See PEP394 for details on why this should be OK. 2012-12-02 03:31:36 +04:00			`#!/usr/bin/env python2`
initial work to refactor emcc into emcc, emld, emar, emranlib 2011-12-14 23:12:19 +04:00
			`'''`
generate .o by default, not .bc. fixes test_zlib 2011-12-15 05:01:16 +04:00			`emar - ar helper script`
initial work to refactor emcc into emcc, emld, emar, emranlib 2011-12-14 23:12:19 +04:00			`=======================`

			`This script acts as a frontend replacement for ar. See emcc.`
			`'''`

Misc fixes for Windows. Most of these changes have to do with how python scripts are invoked. For Linux, 'Popen([EMCC] + args)' works because the first line in emcc is '#!/usr/bin/env python'. On Windows, the python interpreter has to be explicitly invoked, e.g. 'Popen(['python', EMCC] + args)'. Note that there is no harm in explicitly invoking the python interpreter on Linux, so this works on both platforms. For Windows, execvp() behaves differently than on Linux: http://mail.python.org/pipermail/python-list/2002-July/763863.html http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx This causes many strange things to happen as the parent process terminated before its children. In this change the use of execvp() has been replaced with subprocess.call(). This change also fixes some code that assumed that the path separator always is '/', but for Windows it is '\'. And where the path module can be required, we use path.normalize() and path.resolve() to check if a filename is absolute in a platform agnostic manner. 2012-03-20 17:26:50 +04:00			`import os, subprocess, sys`
generate .o by default, not .bc. fixes test_zlib 2011-12-15 05:01:16 +04:00			`from tools import shared`

			`DEBUG = os.environ.get('EMCC_DEBUG')`
add cache debugging 2013-02-27 04:39:14 +04:00			`if DEBUG == "0":`
			`DEBUG = None`
generate .o by default, not .bc. fixes test_zlib 2011-12-15 05:01:16 +04:00
Use llvm-ar instead of llvm-link in emar This makes the semantics of emar to be the same as the semantics of system ar. 2012-02-08 02:05:22 +04:00			`newargs = [shared.LLVM_AR] + sys.argv[1:]`
generate .o by default, not .bc. fixes test_zlib 2011-12-15 05:01:16 +04:00
			`if DEBUG:`
			`print >> sys.stderr, 'emar:', sys.argv, ' ==> ', newargs`

make emcc and emar more robust against odd makefile inputs 2011-12-17 09:55:39 +04:00			`if len(newargs) > 2:`
Misc fixes for Windows. Most of these changes have to do with how python scripts are invoked. For Linux, 'Popen([EMCC] + args)' works because the first line in emcc is '#!/usr/bin/env python'. On Windows, the python interpreter has to be explicitly invoked, e.g. 'Popen(['python', EMCC] + args)'. Note that there is no harm in explicitly invoking the python interpreter on Linux, so this works on both platforms. For Windows, execvp() behaves differently than on Linux: http://mail.python.org/pipermail/python-list/2002-July/763863.html http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx This causes many strange things to happen as the parent process terminated before its children. In this change the use of execvp() has been replaced with subprocess.call(). This change also fixes some code that assumed that the path separator always is '/', but for Windows it is '\'. And where the path module can be required, we use path.normalize() and path.resolve() to check if a filename is absolute in a platform agnostic manner. 2012-03-20 17:26:50 +04:00			`subprocess.call(newargs)`
initial work to refactor emcc into emcc, emld, emar, emranlib 2011-12-14 23:12:19 +04:00