151–160 of 248 posts
Earlier quoted context omitted.
Have you tried Waf? http://code.google.com/p/waf/ Seems like it might be a good fit.
How does Waf compare to SCons? I'm a big fan of SCons, although it annoyingly does not have transitive dependency resolution for libraries. Waf has this functionality, correct?
Earlier quoted context omitted.
Assuming you're building your own code and are willing to arrange things in a compatible manner, then I have a solution to offer. It figures out the dependencies by reading the source code . You can create objects and binaries just by asking it to build a certain target. I recorded an example of installing and using it here: http://rachelbythebay.com/jvt/view?bb_install You can get a copy for experimentation here: ht…
> willing to arrange things in a compatible manner, then I have a solution to offer. So you're proposing that people give up screwdrivers because figuring out what bit to use is hard, and that they should instead use your potato peeler, never mind that it doesn't actually drive screws?
Even for projects that use more sophisticated build tools like rebar, leiningen or npm I write a Makefile so I don't have to remember those tools. Make provides a universal interface to those tools.
I've used Make in a similar context: building documents. Raw simulation results (.log) -> Processed for plotting (.plot) -> Ugly Fig files (.x.fig) -> Pretty Fig files (.fig) -> EPS files (.eps) -> The final document (.pdf). By including the right dependencies in there, you can have individual figures update themselves when the raw data changes, and whole swathes of charts update themselves when the 'fixer' scripts g…
Once the per-month operations were done, all the results were combined into various plots and html pages. There were about 120 months, and running one month took several CPU hours.
I put it all in a makefile. It saved a huge amount of time to not have to repeat all the data reduction (for each month) whenever the plots and subsequent analysis needed to be updated due to an underlying parameter change for a few months' data. I could run make and know that all the per-month changes would roll up correctly to the per-year and overall summaries.
Also, the -j argument to make handled parallelizing the data reduction at zero cost to me.
Absolutely do not use make for any new project. If you love make, it's a big, red, burning flag that you're not demanding enough of your tools and that you're not keeping up with changes in your ecosystem. There are many, many way better alternatives to make. Which one is better depends on the platform you're on. The majority of them throws in automatic dependency management for free. Yes, I know that the essence of…
If you are on a unix system, "redo" (designed by djb and implemented by apenwarr) is excellent. It's refreshingly simple and robust. And, there's a minimalist version called "do" which is a hundred-or-so lines of shell, that does a complete rebuild (no dependency tracking) - so you can package that with your project, and not have to worry about your users having to install yet another build system. Other alternatives…
Earlier quoted context omitted.
If you are on a unix system, "redo" (designed by djb and implemented by apenwarr) is excellent. It's refreshingly simple and robust. And, there's a minimalist version called "do" which is a hundred-or-so lines of shell, that does a complete rebuild (no dependency tracking) - so you can package that with your project, and not have to worry about your users having to install yet another build system. Other alternatives…
waf is cross-platform (Python) https://code.google.com/p/waf/
Earlier quoted context omitted.
If Make is a local optimum and close to a global optimum, it by definition is the global optimum.
Say you have a city with two skyscrapers on opposite sides of town, one 49 stories high and the other 51 stories high. When you're at the top of the 49-story building, you're at a local maximum of height and close to the global maximum, but you're not exactly a short gradient-ascent jaunt away from the global maximum.
If your project sports auto-generated code, or any sort of build targets that depend on inputs only known after generation -- Make simply cannot handle this. There are ugly workarounds but they don't work well. Make is: * Slow (e.g: when compared with tup[1]) * Very easy to get it wrong (under-specify dependencies), with cryptic bugs (or over-building) as a result. Pretty difficult to get it right (e.g: doing proper…
Hmm. I write a lot of generated code and have not found this to be true at all. Many of my projects have multiple levels of code generation that and make handles them just fine. The key is to play to make's strengths and define pattern rules so you can hook into rules engine. Nothing like typing make and having it know to run a script to generate a text file that is further processed by another tool to generate more files that eventually get compiled to produce what you want.
Earlier quoted context omitted.
Why does the pdf version cost more than the paperback?
I'd really like an answer to this. It greatly annoys me when I see this type of thing and it always pisses me off so much that I usually forego getting the book. Perhaps I'm over reacting, but to me, it indicates a lack of respect for the audience. Are we so stupid 1) we won't notice, and 2) we can't figure out mailing a physical thing has to have more overhead than the digital copy?
Absolutely do not use make for any new project. If you love make, it's a big, red, burning flag that you're not demanding enough of your tools and that you're not keeping up with changes in your ecosystem. There are many, many way better alternatives to make. Which one is better depends on the platform you're on. The majority of them throws in automatic dependency management for free. Yes, I know that the essence of…
> There are many, many way better alternatives to make. Which one is better depends on the platform you're on. There's your answer: there are many alternatives, but only one make. Ok maybe 2 o 4. :) But a build system should for the most part be platform agnostic. I have such a hard time understanding why so many programming languages seem to need their own Make alternative (Rake, Cake, Fake, ...?)
...but so are bash scripts.
I wouldn't advocate actually using either of these though, unless the situation is appropriate.
Every system and platform has different requirements, and its a bit of a big ask to want make to be 'the right tool' for all of them.
Certainly, I'd never use make to look after a ruby project, or a c project. That doesn't mean I think make is horrible and I'd never use it for anything, but you can see, perhaps, how something as low level as make might not provide all the tools (dependency management, downloading resources from git hub, automatically tracking system information, a templating system for generating system-dependent headers) you might need for some things.
You could think about it this way: If make did all of these things and was easy to use, there wouldnt be all of these other clones and different attempts at the same thing.
...but there are. So there's certainly something about it isn't making people happy.