Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Waf is also much nicer for end-users, if you're the sort who distributes source packages. It mimics the "./configure; make; make install" sequence as "./waf configure; ./waf; ./waf install".


sort by: page size:

For the casual Linux user, can you explain why './configure && make && make install' is a bad idea? Thanks.

It would be funny --- if it wasn't so tragic --- how much easier to use and manage free software is. Especially considering it's almost all just './configure ; make && make install' at the base level.

I friggin' love pacman.


Same thing here. My own scripts to configure a new Arch install automatically. Much quicker to install with the few things I want to install, than installing Ubuntu (for example) which bundles everything in, and more. It also does exactly what I script it do, so my scripts install specific versions of software whose version really matters. No surprises.

My custom Emacs configuration build? Automated my own way. My AwesomeWM configuration? Automated my own way.

I'm so glad I took the time to learn to do stuff manually, so I could tell them specifically how I want them done automatically. And it should last me quite a while.


Not to be a smart ass but... ./configure, make, make install.

easier way to install per-user software.

Not "easy", but a real, functional option- compile from source in your home folder, targeting ~/bin, ~/lib, etc. The onus is entirely on the user, of course.


Personally I've always found it easier to do:

  $ go install ./...
  $ <cmd name>

No worse than "./configure && make && sudo make install"

My idea of a simple intuitive process is ./configure; make; make install.

Is that deprecated for some reason these days?


I like having the option, tbh. I usually self host the install scripts, which removes most of the potential issues.

> That means you can stick your setup file on a brand-new machine, start emacs, and all your packages auto-install themselves and start working.

This is easy to do with package.el:

(defvar my-packages '(starter-kit scpaste paredit))

(dolist (p my-packages) (when (not (package-installed-p p)) (package-install p)))

I think el-get made sense before community package sources like Marmalade and MELPA existed, but I don't see the point these days.


2nd that, said elsewhere too. If there are multiple tutorials on installing a package, I always pick the DO one first!

Similarly, adding a setup.sh for clean installs doesn't hurt.

Not really. Most web developers are scare of using the cli.

Last time I checked the WP install process was something like...

1. download zip, extract

2. change your some config file

3. upload whole folder using FTP

4. go to /install or something, and from there..

5. click, click, click, edit text, click, click, click ...

That was only if the web developer was in hardcore mode, otherwise it was just _log into cpanel to use one-click installer_


Isn't that only useful for the very rare minority of people that install packages then don't run the code right after? :)

I find the install even easier now thanks to RVM, which is just a copy and paste into the terminal. Same with POW, which is good for the server part of development.

But then again, all this seems easy to me, can't speak for people entirely new to development.


> the easiest method for beginners

Why do people think this way? Honest question.

People create "installers" like these with the goal of making Just One Command that Does Everything For You, saying stuff like "easiest method for beginners". This is suboptimal for many reasons.

I don't want Just One Command that Does Everything For Me. I control the machine; I want to command it myself. This is one of Linux's main selling points. But even for people who don't think this way and just want to install your software quickly, I have concerns.

Providing this installer script as the only way to install your software distribution is actually setting people up for failure:

- Nobody knows how the script works, if it fails they have no way to debug what happened except grepping for log messages in the source code and guessing. At that point just read the whole script and do it manually.

- If the script isn't compatible with their setup, they can't just do the equivalent for their computer, because they might not even know what they need to do. And even if they do figure it out, how will they move on to the next step? They can't just re-run the script if it's not compatible with their setup, remember. Back to reading the whole script and doing it manually.

- The script performs arbitrary changes to their system configuration without asking, like updating repositories(!) and installing dependencies. That's not an OK thing for you to do without asking. And on some rolling-release distributions, like Arch, you never want to update repositories carelessly. Because, if the rest of the system's packages are left outdated after a repository update, they may no longer be compatible with the latest packages available upstream. But you update repositories, on Arch, without telling the user you did so. On Arch, one of the most active rolling-release distributions. So not only will the dependencies you install yourself not necessarily be compatible with the rest of the system—because Arch—random future package installs may also be screwed until the next full system upgrade. Which may never happen if the user never figures out what the problem is.

I sort of lost interest in installing the thing myself, so I never completed my personal audit, but I would recommend, at the very least, not installing packages or updating repositories without prompting first, and also publishing documentation on how to install this without running a fricken' shell script as root, which is not even an acceptable thing to teach "beginners" in the first place. They should be taught not to run things they don't trust, and definitely not to blindly run any shell script from any random website as root.

Sure, it may be 'easy' (for some definition of easy) for 'beginners' (for some definition of beginners) but please don't.


None of those commands are so long that you shouldn't just be retyping them by hand. It's obviously not an ideal way to install anything, but it's much safer than copy and pasting.

I've always been surprised when my friends mention how hard it is to install FOSS packages from scratch. I mean what can be more natural than

    cd directory
    ./configure
    make
    make install
it's almost like in the real life:

    cd kitchen
    ./configure microwave
    make pizza
Isn't it? ;-)

What makes this a worse "installation story" than e.g.

apt install, pip install, git clone && ./configure && make && make install?

next

Legal | privacy