* Why is the "build" target still there?
* Why don't you use `$^` in rules like the one for "bootstrap/js/.js" instead of listing out the files by hand?
A lot of your rules have a wildcard in the target part, which means something like `bootstrap/css/.css: less/.less` actually expands to "bootstrap/css/bootstrap.css bootstrap/css/bootstrap-responsive.css bootstrap/css/bootstrap.min.css bootstrap/css/bootstrap-responsive.min.css: less/bootstrap.less less/responsive.less". THAT expands to:
Thanks! I'm not a make expert by any means, so any improvements are welcome.. I just did the minimum amount to make it faster.
I knew the wildcards would expand, but the subsequent expansions would have their dependencies fulfilled by the first one of them that triggered the commands, so it should short circuit (however you are right, it will be wonky under -j).
I left the "build" target in case I submit a pull request upstream and didn't want to completely upset the apple-cart; it's still useful to compile the docs.
Also, I just pushed another update to my repo, just fyi in case you are editing for a pull request.
Random question for someone way more experienced with this than me...!
With Bootstrap i've never figured out, am i supposed to hack the bootstrap less directly or am i supposed to treat bootstrap as a vendor library and craft my styles separately on top?
The latter seems to be the case, but can't be sure.
Also i've not seen a definitive list of what styles are available with a description of what they're used for, e.g. "jumbotron" appeared in a recent release of bootstrap but i wasn't sure where it could be used or what for.
You can do both, and in between there is a third way of specifying different variables in variables.less to get e.g. a different font, or link color without much hacking involved. It really depends on how much you intend to deviate from the standard look.
Over time, as more people re-use Bootstrap, it seems to be getting more customisable with less hardcoded assumptions so more is possible just via variables.
Bootswatch has some examples of how to make things look quite different while not diverging too much from Bootstrap code so that you can pull in upstream changes with relative ease.
LESS is pretty cool, even aside from Bootstrap, so it might be worth looking at that anyway.
How the hell do you use Bootstrap, directly `@import`ed into LESS?
I'm learning HTML/CSS for the first time (this century, anyway), and I keep reading about the virtues of semantic markup and the evils of presentational classes and markup, and am totally ready to drink the koolaid. I keep seeing LESS/SASS referenced as important tools in achieving this all tersely; and I would rather not have to dig into custom styling and design until after I've got a broader picture, and also have a vague notion that it handles cross-browser inconsistencies for you, so I'm trying to use Bootstrap. Using them together has been an ungodly massive pain, and most components aren't working at all.
Am I having a fundamental misunderstanding of these concepts, or is it just totally not usable in the way I've been struggling to use it?
Basic things like `.btn-group`, and `.input-prepend`, do not work when applied with LESS. Many components, documented in the official Bootstrap docs, and properly exposed in the compiled CSS, either aren't in scope or are not fully applied, when mixed in. Styles will apply properly when put in `<ul class=".btn-group">`, but that's what I thought LESS was supposed to help you get away from. `.container` works with `Bootstrap-SASS`[0], but not with the LESS from the official repo[1]. A massive and unpredictable amount of Bootstrap seems to just not be exposed when importing the LESS source, and what is and isn't, and how to use what isn't, doesn't seem to be documented anywhere. The handful of stackoverflow answers on the topic only ever reference `.makeRow` and `.makeColumn(n)`, with no acknowledgement of the wider issue.
It's wasted hours and hours of my time, trying to figure this all out. It's infuriating.
Would I have a better experience with Zurb Foundation, or some other framework? Is Bootstrap badly documented, or badly designed, or am I just a dumb neophyte missing something major?
It sounds like you are wanting to use some classes (like btn-group) as mixins, when this would not be a good practice, even if it worked the way you are attempting. You don't want to compile the btn-group less to css in every instance of it's usage, it would be repetitive. That's why it's a class rather than a mixin. I see mixins mainly as timesavers to simplify stuff which requires browser prefixes or can be reused through variables. So I wouldn't want to drop .btn-group into a customized class I'm writing, I'd just include it in <ul class="btn-group custom-class">.
I might be misunderstanding you, and I might just be wrong (I am not a less expert).
Makes sense from a practical standpoint, but I think what I'm looking for is something that, while widely advocated[0], either:
-Doesn't seem to be common practice
-I'm misunderstanding
-Bootstrap's LESS just doesn't support, or at least leaves totally undocumented
Doing stuff like this seems to be one of the major motivations behind LESS/SASS in the first place [1][2]. Basically what I want to say is that <ul> (probably a particular subset of <ul>s, specified by selector combinators) should be styled like a .btn-group. That is the behaviour I'd naively expect, and is certainly the behaviour I want. However it can be done [3].
Also, in SASS, you would use selector inheritance -- `ul {@extend .btn-group}` -- which would compile to `ul, .btn-group {...}` and not bloat the output CSS... if it worked at all.
But something either in the design of Bootstrap's LESS (and carried over into the bootstrap-sass port), or in some inherent limitations of LESS/SASS, prevents this. The only way it seems to work is directly applying the presentational class in your HTML, as you've suggested.
So what I'm trying to figure out is whether my expectations are faulty, or some stage of the design is faulty. It's possible, and even advocated (though by 3rd-parties), to do what I'd like to do with some components of Bootstrap, but not with others. If there is any way at all to be able to not specify <class="btn-group"> in the HTML, and have a preprocessor fully apply the styles, even if it turns out to be a bad idea, I'd love to know it if only for the purposes of learning these frameworks, and better understanding their design.
[3] But I'll fight ravenously against anything less than clean and terse (which is admittedly a weakness of mine, and one that's stunted my programming growth severely)
It probably also wouldn't hurt to ditch the ugly little ASCII art separator bars. I wish developers wouldn't insist on polluting their creations with these nasty things.
This is an awesome improvement to the Makefile for bootstrap. The OP clearly sees the strengths of make and hopefully upstream will incorporate these changes.
Autoconf and Automake? Although they might seem obscure at first glance, the Autotools are stable and reliable for developing robust and efficient build systems, and the mailing lists are always helpful.
I made the suggestion because the Autotools provide a standard way of doing things. If you can shoehorn your project into make distcheck, you're basically done. As you noted above, there were problems with the way he did things that I'm pretty sure would not be there in an Autotools build. Plus, it gives you something expandable instead of a base for more cruft. ./configure is always nice, and any make is about 'automated dependency tracking' so I'm a little unclear as to why that doesn't apply. I guess at this point it's not totally unfeasible to maintain the Makefile by hand.
Let's be honest - the autotools bring a nontrivial amount of cruft to the table, and are regarded as "black magic" by most developers.
The automated dependency tracking that I refer to is how automake-generated Makefiles track dependent headers &c. for some compiled languages. That's not at all relevant for the bootstrap project.
* Why is the "build" target still there? * Why don't you use `$^` in rules like the one for "bootstrap/js/.js" instead of listing out the files by hand? A lot of your rules have a wildcard in the target part, which means something like `bootstrap/css/.css: less/.less` actually expands to "bootstrap/css/bootstrap.css bootstrap/css/bootstrap-responsive.css bootstrap/css/bootstrap.min.css bootstrap/css/bootstrap-responsive.min.css: less/bootstrap.less less/responsive.less". THAT expands to:
bootstrap/css/bootstrap.css: less/bootstrap.less less/responsive.less
bootstrap/css/bootstrap-responsive.css: less/bootstrap.less less/responsive.less
bootstrap/css/bootstrap.min.css: less/bootstrap.less less/responsive.less
bootstrap/css/bootstrap-responsive.min.css: less/bootstrap.less less/responsive.less
(All of which have identical commands.) This can potentially break under a make -j (parallel make).
Hang on. I'll cook up a pull request.