What about contribution packages of Grunt/Gulp?
Build Tools – Make, no more
131–140 of 143 posts
Re: Build Tools – Make, no more
#132Another vote for higher-level meta-build-systems like cmake, premake or scons (I'm using cmake because it has very simple cross-compilation support). My personal road to build-system nirwana looked like this, I'm sure this is fairly common:
- Started using hand-written Makefiles and autoconf. Then someone wants to build on Windows, in Visual Studio nonetheless. Add manually created VStudio project files to the project. Then someone wants to use Xcode, so add manually created Xcode project files. Now you add files, or even need to change a compiler option. Fix the options in the Makefile, open the VisualStudio project, fix the options there, open the project in Xcode, fix the options there. Depending on the project complexity, this can take hours. The next guy needs to build the project in an older VisualStudio version, but the project files are not backward compatible...
- Next step was to create my own "meta-build-system" in TCL (this was around 1999), which takes a simple descriptions of the project (what files to compile into what targets, and the dependencies between target), and creates Makefiles, VStudio-files and Xcode-files, this worked fine until the target project file formats change (happens with every new VisualStudio version).
- Someone then pointed me to cmake which does exactly that but much better (creates Makefiles, VStudio-, Xcode-projects, etc... from a generic description of the sources, targets and their dependencies), and I'm a fairly happy cmake user since then.
- Recently I started to wrap different cmake configuration (combinations of target platforms, build tools/IDE to use, and compile config (Release, Debug, etc...)) under a single python frontend script, since there can be dozens of those cmake configs for one project (target platforms: iOS, Android, OSX, Linux, Windows, emscripten, Google Native Client; build tools: make, ninja, Xcode, VStudio, Eclipse; compile configs: Debug, Release). But the frontend python script only calls cmake with the right options, nothing complicated.
Of course now I'm sorta locked-in to cmake, and setting up a cmake-based build-system can be complex and challenging as well, but the result is an easy to maintain cross-platform build system which also supports IDEs.
I general I'm having a lot less problems compiling cmake-based projects on my OSX and Windows machines then autoconf+Makefile-based projects.
[edit: formatting]
Re: Build Tools – Make, no more
#133Another vote for higher-level meta-build-systems like cmake, premake or scons (I'm using cmake because it has very simple cross-compilation support). My personal road to build-system nirwana looked like this, I'm sure this is fairly common: - Started using hand-written Makefiles and autoconf. Then someone wants to build on Windows, in Visual Studio nonetheless. Add manually created VStudio project files to the projec…
I agree with this. As a cross platform (ie, Windows + OSX + Linux) person who enjoys Visual Studio (XCode less so) I need more than make.
My own experience is with gyp and ninja which is used by the Chromium team (http://martine.github.io/ninja/) which they use to build Windows, OSX, Linux, Android (and maybe iOS?)
Of course for personal projects I'll probably never notice the speed difference but for bigger ones Ninja is FAST.
Re: Build Tools – Make, no more
#134Earlier quoted context omitted.
I find them irritating for the same reason. It reminds me of the jQuery cycle: use jQuery for everything -> decide that depending on frameworks is lame -> use "vanilla JS" for everything -> realize this requires polyfills and various other inconvenient, inelegant things -> either go back to using jQuery, or gain a much deeper understanding as to why everyone uses it.
I doubt the analogy is apt. Make is not an amazing (abit slightly bloated) meta tool that solves all your problems on all platforms (abit slowly). Make is vanilla javascript, along with all the bumps and hassles of not working correctly on multiple platforms, having odd obscure syntactic oddities and only kind of supporting various operations in newer versions (which may or may not be available on various platforms).…
That was exactly the analogy the gp was making...
Make -> VanillaJS
Grunt/Rake/whatever -> jQuery
Re: Build Tools – Make, no more
#135strange that scons, http://www.scons.org/, isn't listed there.
Re: Build Tools – Make, no more
#136What about having your text editor do the build for you (use `.dir-locals.el` in emacs to compile your less on save for example)
Re: Build Tools – Make, no more
#137Earlier quoted context omitted.
I don't understand. If both the .o and the .a are created from another file, wouldn't it be safe to just rely on either one of them? (Obviously, you will need to be consistent in choice.) That is, if every time a .o is created, so is the .a, then where is the difficulty? Just rely on one (the .o). I could conceive of a scenario where the .a updated but the .o didn't, but I don't know of any tools that really work tha…
Say you have a long build process and do a quick semi-clean by hand to speed up the next buld (not the best idea, but not inconceivable), deleting the .a files, but fogetting to delete the matching .o files. Then, your next build will produce some novel (to you) error messages that may take long to clean up. Worse, the command building on the .o and the .a might just say "OK, I'm given a .o without a .a; fine, then I…
Ok, that makes sense. I'm tempted to rattle the knee jerk, "don't go deleting random crap," but I realize that is a hollow response.
I'm curious how .INTERMEDIATE helps in this case. I did find this link[1], which was a rather fun read down how one might go about solving this, along with all of the inherent problems.
[1] http://www.gnu.org/software/automake/manual/html_node/Multip...
Re: Build Tools – Make, no more
#138the last 10 years in build tools has felt like 1 step forward, two steps back. i like being able to write tasks in any language other than Makefile. however, it seems like many of the new popular options (cake, grunt, etc.) don't do what, to me, is Make's real purpose: resolve dependencies and only rebuild what's necessary. new task runners have either eliminated or pigeonholed the (typically one-to-one in makeland)…
Yes. And then combine that dependency tree resolution with make -j. Simple and powerful.
Re: Build Tools – Make, no more
#139Earlier quoted context omitted.
I doubt the analogy is apt. Make is not an amazing (abit slightly bloated) meta tool that solves all your problems on all platforms (abit slowly). Make is vanilla javascript, along with all the bumps and hassles of not working correctly on multiple platforms, having odd obscure syntactic oddities and only kind of supporting various operations in newer versions (which may or may not be available on various platforms).…
That was exactly the analogy the gp was making... Make -> VanillaJS Grunt/Rake/whatever -> jQuery
Taking the analogy a bit further, a vanilla proponent might put Make in the second category as well. Funny that modern web development requires a build process to change a line of CSS.
Re: Build Tools – Make, no more
#140Might go a bit off topic but i have to bring this up since 9 out of 10 make tutorials on the internet do the same horrific mistake as you just did, 11 out of 10 code bases out in the wild as well. In your make file example the .o files are just depending on the .cpp files, not the header files they include, the header files those included header files include and the files they include etc etc. This means nothing wil…
This is eminently possible with make-plus-GCC - add the line: .depend : gcc -M *.c > .depend then at the bottom: source .depend
Thank you for that useful option.
Just a nitpick: did you mean `include .depend`?