Re: [dev] Reasonable Makefiles

2014-03-10 Thread Roberto E. Vargas Caballero
> So the Makefile has this: > > all: autoconfig $(BIN) > > autoconfig: > sh config.uname >> config.mk > touch $@ > > and config.uname is a shell script along these lines: > > #!/bin/sh > > os=`uname` > > case $os in > Darwin ) > echo 'Configuring for Darwin' >&

Re: [dev] Reasonable Makefiles

2014-03-10 Thread Nick
Quoth Nick: > Basically because I'm replacing a autotools horrorshow with > plain make, but am not sure what the nicest way of allowing compile- > time feature disabling is. Can 'ifdef' be relied upon, and does it > tend to produce unreadable and buggy makefiles in anyone's > experience? Are there

Re: [dev] Shell vs C where is the border?

2014-03-10 Thread Paul Onyschuk
On Mon, 10 Mar 2014 20:39:08 +0100 Szymon Olewniczak wrote: > But having so many individual programs is more harder to use that just > one (we need to run more commands), so reasonable would be to combine > all this commands to one script which would do all this work > automaticaly. So what solut

Re: [dev] Shell vs C where is the border?

2014-03-10 Thread Chris Down
Szymon Olewniczak writes: > But having so many individual programs is more harder to use that just > one (we need to run more commands), so reasonable would be to combine > all this commands to one script which would do all this work > automaticaly. So what solution would be better in your opinion?

Re: [dev] Shell vs C where is the border?

2014-03-10 Thread Ryan O’Hara
On Mon, Mar 10, 2014 at 12:39 PM, Szymon Olewniczak wrote: > So what solution would be better in your opinion? When > we should use shell scripts and when write new C programs to achieve our > goals? When it makes sense.

[dev] Shell vs C where is the border?

2014-03-10 Thread Szymon Olewniczak
Hi, I was recetly wondering about the use cases of C and shell. I've seen that this topic appears several times mostly when discussing sbase. Some of you probably knows ffmpeg, software that allows to convert media files between various formats. Imagine now that we have several smaller tools that d

Re: [dev] Screencasts?

2014-03-10 Thread Noah Birnel
> Pay attention when things seem too slow or, in your words, feel too > clunky. That's telling you there's a rough edge you need to smooth > down. But once it's fixed and no longer bothering you, there's really > no need to go on fussing over it. > I'll echo that, but suggest that maybe what you

Re: [dev] Screencasts?

2014-03-10 Thread Charlie Kester
On Mon 10 Mar 2014 at 09:29:16 PDT Charlie Kester wrote: Pay attention when things seem too slow or, in your words, feel too clunky. That's telling you there's a rough edge you need to smooth down. But once it's fixed and no longer bothering you, there's really no need to go on fussing over it

Re: [dev] Screencasts?

2014-03-10 Thread Charlie Kester
On Sun 09 Mar 2014 at 12:54:11 PDT Caleb Malchik wrote: I switched to Linux/cli/dwm from OS X just a few years ago, and since the switch I feel the way I do certain basic things is embarrassingly inefficient. For example, if I find an article on the web I want to come back to, I will copy the

Re: [dev] Screencasts?

2014-03-10 Thread Christophe-Marie Duquesne
On Mon, Mar 10, 2014 at 6:33 AM, Christoph Lohmann <2...@r-36.net> wrote: > Stop spreading this screencast crap. Use some expressive > language, maybe a screenshot and _text_ to describe what you are doing. > This is easier to read, can be easier stored, searched / grepped, trans‐ > lated, changed

Re: [dev] Screencasts?

2014-03-10 Thread Dmitrij D. Czarkoff
Kai Hendry said: > Videos should be easier to store (if they are self-contained), create > and consume. Videos are harder to store (they are a lot larger then every other type of content), to create (video codecs are very bad at encoding text) and - the hardest part - to consume (you need to eith