

A Better Makefile for Bootstrap - jazzychad
http://blog.jazzychad.net/2012/12/04/better-makefile-for-bootstrap.html

======
endgame
A few questions/thoughts:

* 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.

~~~
jazzychad
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.

~~~
endgame
While trying to merge your update, I accidentally my entire git stash. I'll
have another go later and send you a pull request.

~~~
dbaupp
Depending on what happened, git often keeps old references around for a while,
so, for example, you can recover dropped stashes:
[http://stackoverflow.com/questions/89332/recover-dropped-
sta...](http://stackoverflow.com/questions/89332/recover-dropped-stash-in-git)

~~~
endgame
Success. Thank you.

------
3amOpsGuy
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.

~~~
jewbacca
While we're on the (off-)topic:

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?

\----

[0] <https://github.com/thomas-mcdonald/bootstrap-sass>

[1] <https://github.com/twitter/bootstrap/tree/master/less>

~~~
jcomis
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).

~~~
jewbacca
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.

\----

[0]<https://www.google.ca/search?q=semantic+classes+html>

[1] <http://lesscss.org/>

[2] [http://ruby.bvision.com/blog/please-stop-embedding-
bootstrap...](http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-
classes-in-your-html)

[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)

------
h2s
##################################################

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.

##################################################

------
zmanji
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.

------
jfb
Why background Emacs? That's what make-mode is for!

~~~
jazzychad
bwaahhh??? a cursory google search wasn't very enlightening... teach me your
ways, wise one!

Edit: oh, I see... compilation mode. I've now set C-c c and C-c r to 'compile
and 'recompile respectively. thanks!

~~~
jazzychad
better yet i've added an after-save-hook to 'recompile so when i save the site
is updated by the time i alt-tab over to the browser and reload!

    
    
        M-x eval-expression RET (add-hook 'after-save-hook 'recompile)

------
zx2c4
what you do now:

    
    
        uglify source.js > dest.tmp.js
        echo "/* Copyright blah blah" > copyright.js
        cat copyright.js dest.tmp.js > dest.js
        rm copyright.js dest.tmp.js
    

what you should do:

    
    
        echo "/* Copyright blah blah" > dest.js
        uglify source.js >> dest.js

------
kyrra
6 seconds to compile. Man that would be nice. A think a full build of my
companies product takes 90 minutes.

~~~
mixmastamyk
But what does an incremental build take?

If still bad you might try the Samsung 840 Pro SSD, or even a ramdrive. ;)

------
georgeorwell
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.

~~~
endgame
As someone who has contributed to automake, I do not believe they're not the
correct tools for this job.

You want autoconf either because you want automake, or because you need to do
platform-specific checks to adapt your software.

You want automake to get automated dependency tracking and to get a Makefile
that supports the GNU coding standards.

Neither of these apply here: you're basically chaining together small shell
snippets to build a couple of files. Raw make is the correct tool, IMHO

~~~
georgeorwell
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.

~~~
endgame
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.

