Javascript-based tools

[konsumer]

It makes me happy to see javascript projects using javascript build/dev tools. It would help for incorporating into my own project build system, so I can just take the parts I want. It is also cool because it keeps the whole codebase in a single language, so it's easier to switch between tasks, for me. Another strength of this approach is that you could keep all dependencies outside of version-control (using npm package.json.) Is there interest in converting python tool stack to node/grunt things? If so, is there a succinct list of all tools that people use?

I notice these, that may be candidates for js/grunt equivs:

Makefile - this could be handled by grunt

manage.py - this could be handled by grunt, with similar targets to flag. I might recommend grouping targets, because that is really easy in grunt:

grunt dev (clean, typescript-compile, lint, test)
grunt dev-nolint (clean, typescript-compile, test)

grunt lib (clean, typescript-compile, lint, uglify, test)
grunt nolint (clean, typescript-compile, uglify, test)

With some sub-targets for doc, samples, & tools

It might be nice to also do live-reloading with watch, and incorporate a dev server for file:// URL issues.

tools/cgfx2json - not sure, but this might be accomplished with node-cuda, and integrated as a grunt task, if needed

I have experience with all but the last, and would need to do a bit of research to see if node-cuda would do what is needed. Another option might be to make a very small node library that just exposes what the cpp-file does, and make it a separate project.

[konsumer]

I think some of the current node-based tools could also be incorporated into a grunt/package.json-oriented build procedure, too, if this seemed useful. strip-debug seems most useful as grunt task, as this is part of a deploy/build procedure (and I think can be totally replicated with standard grunt-contrib stuff.) maptool & aesdecrypt seem to be standalone cli-tools could just have their dependencies tracked for easy install with npm, and have their bins tracked, so the project can be easily incorporated into other node projects (bins are auto-installed in the path of npm script and in your system path with npm install -g.)

[dtebbs]

Thanks for the comments.

We may end up moving more tools towards JavaScript, partly because of the potential to use TypeScript for validation. There are certainly advantages to using the same language across tools, but the primary goal for us is to provide standalone tools which can be easily invoked by our build system, or the developers custom build, so we don't have a single language policy for tools.

I haven't looked at grunt, but the Make syntax is very well suited to constructing command lines, and specifying files, dependencies and rules without any underlying language getting in the way (whether it's JavaScript, Ruby, Python, etc), so I've never had much success with any of the Make replacements out there (except maybe Jam), but it may just be a matter of taste :)

And the npm package for JS tools is a good idea, and something we are definitely looking at.

[konsumer]

I hear that. I think the mono-language thing is totally a matter of taste on my part, as I am a huge fan of not having to switch gears too much to work on things. If it is actually important to maintain non-JS/TS tools, then there is probably little point to grunt. grunt's not so much a "Make replacement" as a quick frontend for common JS/web build-tasks, but definitely not for everyone. For actual making of CPP/python things, it's not really for that. That said, I still believe that most of the non-JS/TS stuff seems mostly in support of the build system, and would not be needed, if the build system could do things directly like uglify/string-replace/compile-typescript/compile-shaders/etc. The command-line tools not related directly to build are mostly in node, now (except for shader stuff in CPP.)

I used to really like python the best, and am ok with C, but nowadays, if it's a javascript project that has things that need to be done to deploy, grunt does it really well. If I need native stuff, I try to replace it with node code or if I really have to, wrap it in node modules. node has awesome building & dep-tracking (node-gyp), and seems to cause less troubles multi-platform than anything else I have used. This saves a lot of time for me, while imposing very little dependency install/learning burden on the devs who touch my code.

My own opinions on tools aside, If grunt/python-replacement doesn't sound like a good idea, I'd be happy to help with npm stuff.

[davidgaleano]

Just for the record, the tool cgfx2json is written in C++ because we use the Cg Toolkit libraries from NVIDIA to translate our CgFX shaders into GLSL code and JSON structures that WebGL and JavaScript understand. This has nothing to do with CUDA, they are different technologies, so I doubt node-cuda will help in replacing it. In my opinion the best approach to replace cgfx2json by a node.js solution would be to invoke the Cg Toolkit binaries to extract the compiled GLSL code from the CgFX files, but I think there would be still some extra work required to parse and translate the techniques and render states.

[konsumer]

Yep, sounds right. I don't know much about cuda, or node-cuda, but I vaguely remember cuda lib having Cg dependency to mess with shaders somehow. I could have this totally wrong, as I only played with it for a second, a while ago. That said, anything written in C++, can pretty quickly be wrapped with node lib, and integrated into node's native build tools (which, as I mentioned are pretty sweet.) Even without any CPP wrapping code, tools like node-ffi can make this process pretty simple, and doesn't require compile if the native lib has externs. Also, a node Cg wrapper would probably be useful to everyone, not just devs of turbulenz, but even in a simpler form (incomplete binding, just for what turbulenz needs), it would still be awesome for times when anyone needs to parse/compile shaders in javascript.

[dtebbs]

Sounds like I misunderstood grunt then. If it can help us package the JS tools up then that could be the solution.
Thanks for the pull request, btw.

I'll be looking at this stuff again in the near future, at which point I'll grab your changes and get the npm package sorted out.

Thanks.

[konsumer]

No prob, hope it's useful! I kept file structure modifications & tool choices to an absolute minimum with the pull request. It doesn't actually do anything except track the info I found in the repo (project name, version, contributors, license.) I'd be happy to make it more useful, I was just unsure of how much to move things around (for example I didn't remove uglify as submodule, and add as a dep, setup grunt, etc.) If there is a central person who focuses on packaging/building, I'd be happy to work closer with them to ensure it does what you want. I like turbulenz, and will be using it in my own system with grunt, so it's not really extra work, just wanna make sure my additions to repo are actually useful to others who use it.

[konsumer]

Tonight, I'd like to just make a minimal build version, only JS & grunt, just for myself, and would be happy to share as a branch of this repo, if it'd be illustrative to others.

[konsumer]

hmm. maybe not: lots of errors. Will need to investigate.

Lot's of error TS1008: Unexpected token; 'constructor, function, accessor or variable' expected. Probably doing somehting wrong.

[fvilca]

I need your help
I love Turbulenz
I am new to this

I am following this tutorial:

http://docs.turbulenz.com/starter/getting_started_guide.html # loading

• INSTALLDIR * / tools / bin / * PLATFORM * / cgfx2json \
     -i * INSTALLDIR * / assets/shaders/generic3D.cgfx \
     -o generic3D.cgfx.json

and when I run this command:

• INSTALLDIR * not recognized as an internal command or ...

Thanks, Thanks

[ianballantyne]

You need to replace the INSTALLDIR with the directory for the SDK/open source. e.g. For windows:
C:\Turbulenz\SDK\0.28.0

or for mac/linux:

~/Turbulenz/SDK/0.28.0