File globbing on windows

[ibell]

On Windows, when I try to use file globs, they don't work. FWIW, file globs work on linux.

Example

dir *.cpp
C:\Users\Belli\Documents\Code\emscripten\em++ *.cpp

yields

 Volume in drive C is Windows7_OS
 Volume Serial Number is 8E2A-26D8

 Directory of C:\Users\Belli\Documents\Code\CoolProp\CoolProp

09/22/2013  04:07 PM             1,927 AllFluids.cpp
08/11/2013  01:50 PM            23,349 Brine.cpp
09/27/2013  12:13 PM            32,092 CoolProp.cpp
09/21/2013  10:42 PM            12,556 CoolPropDLL.cpp
09/15/2013  11:09 PM             5,817 CoolPropTools.cpp
09/26/2013  05:03 PM            75,761 CPState.cpp
08/11/2013  01:50 PM             1,314 CriticalSplineConstants.cpp
09/25/2013  02:22 PM           123,579 FluidClass.cpp
09/27/2013  01:30 PM            63,760 Helmholtz.cpp
09/27/2013  12:13 PM            52,806 HumidAirProp.cpp
08/11/2013  01:50 PM             3,926 Ice.cpp
09/27/2013  12:13 PM            11,313 IncompBase.cpp
09/27/2013  12:13 PM             3,796 IncompLiquid.cpp
09/27/2013  12:13 PM             6,861 IncompSolution.cpp
09/27/2013  12:13 PM             4,171 MatrixMath.cpp
09/15/2013  11:09 PM            27,533 Mixtures.cpp
09/15/2013  11:09 PM             2,844 PengRobinson.cpp
09/21/2013  09:49 PM            43,289 REFPROP.cpp
09/19/2013  04:54 PM             8,506 Solvers.cpp
09/11/2013  03:20 PM             1,081 Spline.cpp
09/26/2013  05:29 PM            85,778 TTSE.cpp
09/27/2013  12:13 PM             3,150 Units.cpp
              22 File(s)        595,209 bytes
               0 Dir(s)  16,914,239,488 bytes free

C:\Users\Belli\Documents\Code\CoolProp\CoolProp>C:\Users\Belli\Documents\Code\emscripten\em++ *.cpp 
ERROR    root: *.cpp: No such file or directory

so it is clearly not handling the glob properly.

[ngld]

Normally the shell handles the glob and passes emscripten the expanded parameter. It seems windows doesn't do that.

[kripken]

I assume this is a windows limitation, yeah. Perhaps @juj knows better?

[ibell]

I have used file globbing on windows before, so I know its not a limitation with windows. For instance, you can do something like

erase *.obj

to erase all object files

On Sun, Sep 29, 2013 at 8:52 PM, Alon Zakai notifications@github.comwrote:

I assume this is a windows limitation, yeah. Perhaps @jujhttps://github.com/jujknows better?

— Reply to this email directly or view it on GitHubhttps://github.com/kripken/emscripten/issues/1675#issuecomment-25326328 .

[juj]

Windows shell/cmd.exe does not expand wildcards like Unix systems do. The emscripten compiler will get the string "*.cpp" on the command line inputs. (e.g. http://superuser.com/questions/460598/is-there-any-way-to-get-the-windows-cmd-shell-to-expand-wildcard-paths )

Testing other tools, It looks like at least mingw32-g++.exe and cl.exe (VS2010 compiler) both support the *.cpp wildcard. clang++.exe does not.

To support this, it would be have to be implemented it in emscripten itself.

[ibell]

Ugh. That's too bad. It makes the build process on windows significantly more annoying. I am trying to limit myself to the use of .bat files to limit the dependencies.

On Mon, Sep 30, 2013 at 5:45 PM, juj notifications@github.com wrote:

Windows shell/cmd.exe does not expand wildcards like Unix systems do. The emscripten compiler will get the string "*.cpp" on the command line inputs. (e.g. http://superuser.com/questions/460598/is-there-any-way-to-get-the-windows-cmd-shell-to-expand-wildcard-paths)

Testing other tools, It looks like at least mingw32-g++.exe and cl.exe (VS2010 compiler) both support the *.cpp wildcard. clang++.exe does not.

To support this, it would be have to be implemented it in emscripten itself.

— Reply to this email directly or view it on GitHubhttps://github.com/kripken/emscripten/issues/1675#issuecomment-25374792 .

[juj]

In case if you or someone else are interested in alternatives at some point, Emscripten has the following support for cross-platform (windows,linux,osx) and cross-target (native,html5) builds:

• hand-write Makefiles (works with make on Unix, and cygwin make on Windows, with some expertise also with mingw32-make on Windows) or use configure-scripts or similar. Possibly way too primitive, but the support is there, since emscripten toolchain looks like a "standard" compiler toolchain. This will most likely add either MinGW or cygwin as a dependency.
• use SCons: There's actually two different scons support code in the Emscripten codebase. This will add python as a dependency.
• use CMake: I actively use and maintain the CMake toolchain support for Emscripten, Even though I hate that it invents its own script language syntax and is generally rather brittle, it has very good platform support. I use it to drive builds for http://clb.demon.fi/gfxapi/ for each platform. This will add the CMake application as a dependency.

Also, if you're Windows-only, you can use vs-tool to drive builds from Visual Studio 2010. That gives a nice dropdown dialog to switch between native Windows build and a HTML5 build.

[stale[bot]]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

[kimiyoribaka]

So, I just got a 5 minute quick and dirty solution to globbing paths in emcc.py that works for me, but I don't know if there'd be issues with other users or when applied to other tools included with emscripten.

The solution I used was to just import the python glob library and intercept the args parameter from the main function, applying globbing to every argument then leaving the argument alone if the result is an empty sequence.

The actual code as it currently looks in my copy of emcc.py is this:

import glob
def glob_args(args):
  new_args = []
  for i in range(len(args)):
    gtable = glob.glob(args[i])
    if len(gtable) > 0:
      for s in gtable:
        new_args.append(s)
    else:
      new_args.append(args[i])
  return new_args

#
# Main run() function
#
def run(args):
  args = glob_args(args)

  if shared.run_via_emxx:
    clang = shared.CLANG_CXX
  else:
    clang = shared.CLANG_CC

I hope that helps at least somewhat.

[sbc100]

I'd be in favor of supporting whatever clang supports. If clang itself doesn't' support such things I don't think we should either.