Documentation -- what I ran into when I installed kerl

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Documentation -- what I ran into when I installed kerl

Lloyd R. Prentice-2

Hello,

 

We all know that writing software documentation is hard. I tip my hat to all who strive to do it well.

 

My sense is that software docs are living documents ideally drafted through an iterative process that involves several cycles of unwitting users attempting to follow the how-to-install/how-to-use recipes proposed in the documentation followed closely on by doc revision based on user experience.

 

This does lead to a challenge: how much can the doc writer reasonably assume about user knowledge and experience?

 

Assume too much and you frustrate naive but motivated users. Assume to little and you risk frustrating knowledgeable users. I really don't know the best compromise. But it is a concern I believe worthy of discussion and debate.

 

For what it's worth, here's what I ran into when I installed kerl:

 

1. First roadblock -- my lack of a lowl-level Linux skill, e.g. adding kerl to PATH. Dan Sommers provided the simple solution:

 

$ cp $HOME/kerl $HOME/bin/

 

Dan's solution worked a charm. Perhap it can be added as an example under the current instruction in kerl docs:

 

"and drop it in your $PATH"

   

2. When I executed $ kerl build 21.1 I again ran into failure-- needed ncurses library. Took 15 minutes to find the right package name, but the solution was:

 

~$ sudo apt-get install libncurses-dev

 

3. Retried $ kerl build 21.1 and it worked but with numerous moans and growns:

 

Building Erlang/OTP 21.1 (21.1), please wait...
WARNING: It appears that a required development package 'automake' is not installed.
WARNING: It appears that a required development package 'autoconf' is not installed.
APPLICATIONS DISABLED (See: /home/lloyd/.kerl/builds/21.1/otp_build_21.1.log)
* jinterface : No Java compiler found
* odbc : ODBC library - link check failed

APPLICATIONS INFORMATION (See: /home/lloyd/.kerl/builds/21.1/otp_build_21.1.log)
* wx : wxWidgets not found, wx will NOT be usable

DOCUMENTATION INFORMATION (See: /home/lloyd/.kerl/builds/21.1/otp_build_21.1.log)
* documentation :
* xsltproc is missing.
* fop is missing.
* xmllint is missing.
* The documentation can not be built.

 

Again,  it took a bit of time looking up package names to meet the requirements. Given that, the following console commands filled in the blanks:

 

~$ sudo apt-get install xsltproc
~$ sudo apt-get install libncurses-dev
~$ sudo apt-get install automake
~$ sudo apt-get install autoconf
~$ sudo apt-get install xsltproc
~$ sudo apt-get install fop

 

Some of these package names may be Ubuntu specific, which certainly makes doc drafting more difficult. But it would have saved considerable time and a bit easier on the blood pressure if kerl docs provided forewarning and, even better, a working example.

 

All that said, thanks to the kerl authors for a very useful tool. My next step now is to build the Erlang docs.

 

Best wishes,

 

Lloyd

 

 

 

 

 

 

 

 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Documentation -- what I ran into when I installed kerl

Fred Hebert-2
On 11/20, [hidden email] wrote:

>
>Hello,
>
>We all know that writing software documentation is hard. I tip my hat
>to all who strive to do it well.
>
>My sense is that software docs are living documents ideally drafted
>through an iterative process that involves several cycles of unwitting
>users attempting to follow the how-to-install/how-to-use recipes
>proposed in the documentation followed closely on by doc revision based
>on user experience.
>
>This does lead to a challenge: how much can the doc writer reasonably
>assume about user knowledge and experience?
>

Hi Lloyd,

I tend to write a decent amount of documentation, and what you state
right here is a major hurdle. It's really hard to figure out your target
audience, and communicate that clearly. It's equally hard to remember
what your system was like before you had installed all the right
dependencies, and it's really easy for things to slip from your mind.

The thing I rely on to help in such cases is reader questions to
highlight the problems I had and the things I forgot.

I didn't write the kerl documentation, so that being said, I don't
necessarily know who it is targeted to. I know I can read it fine, but
I'm no longer a beginner either.

>Assume too much and you frustrate naive but motivated users. Assume to
>little and you risk frustrating knowledgeable users. I really don't
>know the best compromise. But it is a concern I believe worthy of
>discussion and debate.
>

Yes. I think what we are missing as a community is a well-defined "how
to install Erlang on your system" style of documentation that is
well-visible and maintained. That way, tool developers could point to
that document as a foundational step, and people whose setup is complete
can easily skip it.

>For what it's worth, here's what I ran into when I installed kerl:
>
>1. First roadblock -- my lack of a lowl-level Linux skill, e.g. adding
>kerl to PATH. Dan Sommers provided the simple solution:
>
>$ cp $HOME/kerl $HOME/bin/
>
>Dan's solution worked a charm. Perhap it can be added as an example
>under the current instruction in kerl docs:
>
>"and drop it in your $PATH"
>

This only works because Dan noticed that `$HOME/bin/` was already in
your path. But yes, the `$PATH` environment variable is something the
tool author assumed the reader was familiar with.

It's an environment variable that contains directories where common
executables can be found. Your shell of choice (bash, sh, csh, zsh,
etc.) all have a dotfile (.bashrc, .zshrc) where you can do things like

export PATH="$HOME/some/path:$PATH"

which essentially adds $HOME/some/path to the head of all the paths your
shell will look into for executables.


>2. When I executed $ kerl build 21.1 I again ran into failure-- needed
>ncurses library. Took 15 minutes to find the right package name, but
>the solution was:
>
>~$ sudo apt-get install libncurses-dev
>

Right. This, at this point, was a missing dependency of Erlang/OTP
itself. libncurses is a library used to handle fancy terminal output
sequences like those you see when progress bar animations are drawn in
the terminal.

Libncurses-dev is a package containing the source files to that library
so that your own executables can be built against them and also contain
that functionality.

When compiling software, you will often need to download additional
*-dev packages for this reason.

>3. Retried $ kerl build 21.1 and it worked but with numerous moans and
>growns:
>
>Building Erlang/OTP 21.1 (21.1), please wait...
>WARNING: It appears that a required development package 'automake' is
>not installed.
>WARNING: It appears that a required development package 'autoconf' is
>not installed.
>APPLICATIONS DISABLED (See:
>/home/lloyd/.kerl/builds/21.1/otp_build_21.1.log)
> * jinterface : No Java compiler found
> * odbc : ODBC library - link check failed
>APPLICATIONS INFORMATION (See:
>/home/lloyd/.kerl/builds/21.1/otp_build_21.1.log)
> * wx : wxWidgets not found, wx will NOT be usable
>DOCUMENTATION INFORMATION (See:
>/home/lloyd/.kerl/builds/21.1/otp_build_21.1.log)
> * documentation :
> * xsltproc is missing.
> * fop is missing.
> * xmllint is missing.
> * The documentation can not be built.
>

Automake and autoconf are useful to have in general, and it's the kind
of thing that trips me up every time I set up a system for the first
time, but after that you never need to reinstall it again. It is
something I always forget in instructions because unless I do it on a
new machine or virtual machine, it never errors out.

The other errors are optional dependencies for optional libraries
(jinterface lets your erlang talk to java, odbc is a generic database
driver for SQL databases, wx is the graphical toolkit that can be used
by libraries like observer) and dependencies (xsltproc allows XML
processing when building the doc, fop has something to do with PDF
generation of the doc, and xmllint is likely XML validation for the
docs).

Your system should be usable, but if you see a tutorial break when you
call `observer:start()`, it will be because of that missing wx
dependency.

>Some of these package names may be Ubuntu specific, which certainly
>makes doc drafting more difficult. But it would have saved considerable
>time and a bit easier on the blood pressure if kerl docs provided
>forewarning and, even better, a working example.
>

Exactly; these _are_ ubuntu-specific, and each linux distribution may
cut up their packages differently. So documentation writers will tend to
just tell you to get a copy from a package manager, which leaves you on
your own for kerl.

It lets us off the hook for the installation of the system and we
handwave all responsibility away.

I personally run Windows 10, OSX, a LTS copy of Ubuntu, and a FreeBSD
distro on a raspberry pi, and I still avoid some build instructions
because you never really know how things end up when distribution
maintainers change how things are cut up.

Regards,
Fred.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Documentation -- what I ran into when I installed kerl

Lloyd R. Prentice-2
Thank you Fred.

I’ve much admired your work.

> Yes. I think what we are missing as a community is a well-defined "how to install
> Erlang on your system" style of documentation that is well-visible and maintained.
> That way, tool developers could point to that document as a foundational step, and
> people whose setup is complete can easily skip it.

Perhaps working together we can make that happen. As you may have noticed, I don’t mind asking Mickey-The -Dunce questions. I’m pushing hard on several fronts to learn what I need to know to bring Writersglen to fruition. And I’ve learned that one of the best ways to learn is to teach.

In addition to work on erlpress_core, I’ve been trying to wrap my arms around secure Erlang web deployment. Bringing up a site to serve a “how to install
Erlang on your system" tutorial would be a good learning exercise.

Point the way and I’ll do what I can to make this happen.

Lloyd

Sent from my iPad

> On Nov 20, 2018, at 8:24 PM, Fred Hebert <[hidden email]> wrote:
>
> Yes. I think what we are missing as a community is a well-defined "how to install Erlang on your system" style of documentation that is well-visible and maintained. That way, tool developers could point to that document as a foundational step, and people whose setup is complete can easily skip it.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Documentation -- what I ran into when I installed kerl

Ivan Uemlianin
In reply to this post by Lloyd R. Prentice-2
Dear Lloyd

Kerl is fantastic and I use it a lot, but I have struggled with the documentation like you have (in my case getting it to work on a Mac). 

Kerl's documentation is very far from the worst for an open-source project.  The only real way to test installation and "getting started" docs is to have someone not involved in the project to install and run the software --- preferably under observation and at a time and place not of their choosing.

I now have kerl running happily on a Mac and on Ubuntu.  (Feel free to ping me offline if I can help.)

The Unix environment is an ocean in which a gnat may drink and an elephant may bathe, which does complicate things.  In case you haven't come across it already, I find alias very handy, e.g., I have these lines in my .alias file (or you might have .bash_aliases on Ubuntu):

    alias erl18='.  ~/bin/erl_kerl_builds/r183/activate'
    alias erl20='.  ~/bin/erl_kerl_builds/r203/activate'
    alias erl21='.  ~/bin/erl_kerl_builds/r210/activate'

(That '.' is a synonym for the command 'source'.)

So instead of having to type out '.  ~/bin/erl_kerl_builds/r210/activate' I can just use erl21.

Happy hacking!

Ivan


On 20/11/2018 22:37, [hidden email] wrote:

Hello,

 

We all know that writing software documentation is hard. I tip my hat to all who strive to do it well.

 

My sense is that software docs are living documents ideally drafted through an iterative process that involves several cycles of unwitting users attempting to follow the how-to-install/how-to-use recipes proposed in the documentation followed closely on by doc revision based on user experience.

 

This does lead to a challenge: how much can the doc writer reasonably assume about user knowledge and experience?

 

Assume too much and you frustrate naive but motivated users. Assume to little and you risk frustrating knowledgeable users. I really don't know the best compromise. But it is a concern I believe worthy of discussion and debate.

 

For what it's worth, here's what I ran into when I installed kerl:

 

1. First roadblock -- my lack of a lowl-level Linux skill, e.g. adding kerl to PATH. Dan Sommers provided the simple solution:

 

$ cp $HOME/kerl $HOME/bin/

 

Dan's solution worked a charm. Perhap it can be added as an example under the current instruction in kerl docs:

 

"and drop it in your $PATH"

   

2. When I executed $ kerl build 21.1 I again ran into failure-- needed ncurses library. Took 15 minutes to find the right package name, but the solution was:

 

~$ sudo apt-get install libncurses-dev

 

3. Retried $ kerl build 21.1 and it worked but with numerous moans and growns:

 

Building Erlang/OTP 21.1 (21.1), please wait...
WARNING: It appears that a required development package 'automake' is not installed.
WARNING: It appears that a required development package 'autoconf' is not installed.
APPLICATIONS DISABLED (See: /home/lloyd/.kerl/builds/21.1/otp_build_21.1.log)
* jinterface : No Java compiler found
* odbc : ODBC library - link check failed

APPLICATIONS INFORMATION (See: /home/lloyd/.kerl/builds/21.1/otp_build_21.1.log)
* wx : wxWidgets not found, wx will NOT be usable

DOCUMENTATION INFORMATION (See: /home/lloyd/.kerl/builds/21.1/otp_build_21.1.log)
* documentation :
* xsltproc is missing.
* fop is missing.
* xmllint is missing.
* The documentation can not be built.

 

Again,  it took a bit of time looking up package names to meet the requirements. Given that, the following console commands filled in the blanks:

 

~$ sudo apt-get install xsltproc
~$ sudo apt-get install libncurses-dev
~$ sudo apt-get install automake
~$ sudo apt-get install autoconf
~$ sudo apt-get install xsltproc
~$ sudo apt-get install fop

 

Some of these package names may be Ubuntu specific, which certainly makes doc drafting more difficult. But it would have saved considerable time and a bit easier on the blood pressure if kerl docs provided forewarning and, even better, a working example.

 

All that said, thanks to the kerl authors for a very useful tool. My next step now is to build the Erlang docs.

 

Best wishes,

 

Lloyd

 

 

 

 

 

 

 

 



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

-- 
============================================================
Ivan A. Uemlianin PhD
Llaisdy

Ymchwil a Datblygu Technoleg Lleferydd
Speech Technology Research and Development

                    [hidden email]
                        @llaisdy
                         llaisdy.wordpress.com
              github.com/llaisdy
                     www.linkedin.com/in/ivanuemlianin

                        festina lente
============================================================ 

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Documentation -- what I ran into when I installed kerl

Lloyd R. Prentice-2

Thanks for the thoughts and tips, Ivan!

 

Love your quote:

 

"The Unix environment is an ocean in which a gnat may drink and an elephant may bathe"

 

And I would add, "and where a noobie can all too easily flounder around lost at sea."

 

I work alone on many fronts so, beyond the wonderful people on this list, depend upon books and the web as I try to become sufficiently competent in the many tasks required to bring the ambitious web app I've been working on to fruition. Documentation is often a make or break for me when I evaluate an app or tool. If I don't understand it, which happens all too often, it's Sayonara for that app.

 

This is complicated by the fact that as I age I don't retain information as well as I once did. So I've been struggling to develop a format and system for keeping track of all the things I need to know.

 

I hope soon to propose documentation for creating publish source GitHub repositories. If time and energy allow, I'll try to follow it up with a stab at a "Building Erlang on Ubuntu" draft inspired by Fred Hebert's suggestion.

 

I need to understand how to put such documents on the web, so I'll do so as time permits.

 

Thanks again,

 

Lloyd

 

-----Original Message-----
From: "Ivan Uemlianin" <[hidden email]>
Sent: Wednesday, November 21, 2018 6:59am
To: [hidden email]
Subject: Re: [erlang-questions] Documentation -- what I ran into when I installed kerl

Dear Lloyd

Kerl is fantastic and I use it a lot, but I have struggled with the documentation like you have (in my case getting it to work on a Mac). 

Kerl's documentation is very far from the worst for an open-source project.  The only real way to test installation and "getting started" docs is to have someone not involved in the project to install and run the software --- preferably under observation and at a time and place not of their choosing.

I now have kerl running happily on a Mac and on Ubuntu.  (Feel free to ping me offline if I can help.)

The Unix environment is an ocean in which a gnat may drink and an elephant may bathe, which does complicate things.  In case you haven't come across it already, I find alias very handy, e.g., I have these lines in my .alias file (or you might have .bash_aliases on Ubuntu):

    alias erl18='.  ~/bin/erl_kerl_builds/r183/activate'
    alias erl20='.  ~/bin/erl_kerl_builds/r203/activate'
    alias erl21='.  ~/bin/erl_kerl_builds/r210/activate'

(That '.' is a synonym for the command 'source'.)

So instead of having to type out '.  ~/bin/erl_kerl_builds/r210/activate' I can just use erl21.

Happy hacking!

Ivan


On 20/11/2018 22:37, [hidden email] wrote:

Hello,

 

We all know that writing software documentation is hard. I tip my hat to all who strive to do it well.

 

My sense is that software docs are living documents ideally drafted through an iterative process that involves several cycles of unwitting users attempting to follow the how-to-install/how-to-use recipes proposed in the documentation followed closely on by doc revision based on user experience.

 

This does lead to a challenge: how much can the doc writer reasonably assume about user knowledge and experience?

 

Assume too much and you frustrate naive but motivated users. Assume to little and you risk frustrating knowledgeable users. I really don't know the best compromise. But it is a concern I believe worthy of discussion and debate.

 

For what it's worth, here's what I ran into when I installed kerl:

 

1. First roadblock -- my lack of a lowl-level Linux skill, e.g. adding kerl to PATH. Dan Sommers provided the simple solution:

 

$ cp $HOME/kerl $HOME/bin/

 

Dan's solution worked a charm. Perhap it can be added as an example under the current instruction in kerl docs:

 

"and drop it in your $PATH"

   

2. When I executed $ kerl build 21.1 I again ran into failure-- needed ncurses library. Took 15 minutes to find the right package name, but the solution was:

 

~$ sudo apt-get install libncurses-dev

 

3. Retried $ kerl build 21.1 and it worked but with numerous moans and growns:

 

Building Erlang/OTP 21.1 (21.1), please wait...
WARNING: It appears that a required development package 'automake' is not installed.
WARNING: It appears that a required development package 'autoconf' is not installed.
APPLICATIONS DISABLED (See: /home/lloyd/.kerl/builds/21.1/otp_build_21.1.log)
* jinterface : No Java compiler found
* odbc : ODBC library - link check failed

APPLICATIONS INFORMATION (See: /home/lloyd/.kerl/builds/21.1/otp_build_21.1.log)
* wx : wxWidgets not found, wx will NOT be usable

DOCUMENTATION INFORMATION (See: /home/lloyd/.kerl/builds/21.1/otp_build_21.1.log)
* documentation :
* xsltproc is missing.
* fop is missing.
* xmllint is missing.
* The documentation can not be built.

 

Again,  it took a bit of time looking up package names to meet the requirements. Given that, the following console commands filled in the blanks:

 

~$ sudo apt-get install xsltproc
~$ sudo apt-get install libncurses-dev
~$ sudo apt-get install automake
~$ sudo apt-get install autoconf
~$ sudo apt-get install xsltproc
~$ sudo apt-get install fop

 

Some of these package names may be Ubuntu specific, which certainly makes doc drafting more difficult. But it would have saved considerable time and a bit easier on the blood pressure if kerl docs provided forewarning and, even better, a working example.

 

All that said, thanks to the kerl authors for a very useful tool. My next step now is to build the Erlang docs.

 

Best wishes,

 

Lloyd

 

 

 

 

 

 

 

 



_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions


-- ============================================================ Ivan A. Uemlianin PhD Llaisdy Ymchwil a Datblygu Technoleg Lleferydd Speech Technology Research and Development [hidden email] @llaisdy llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Documentation -- what I ran into when I installed kerl

Fred Hebert-2
On 11/21, [hidden email] wrote:
>
>I hope soon to propose documentation for creating publish source GitHub repositories. If time and energy allow, I'll try to follow it up with a stab at a "Building Erlang on Ubuntu" draft inspired by Fred Hebert's suggestion.
>
>I need to understand how to put such documents on the web, so I'll do so as time permits.
>

You can start by putting a document on github, which might make it
easier for people to send contributions and add content, possibly steps
on other frameworks.

That might be the lowest overhead solution at least :)
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Documentation -- what I ran into when I installed kerl

Lloyd R. Prentice-2

Thanks, Fred,

 

I'll do just that!

 

Best wishes,

 

Lloyd

 

 

-----Original Message-----
From: "Fred Hebert" <[hidden email]>
Sent: Wednesday, November 21, 2018 5:56pm
To: [hidden email]
Cc: "Ivan Uemlianin" <[hidden email]>, [hidden email]
Subject: Re: [erlang-questions] Documentation -- what I ran into when I installed kerl

On 11/21, [hidden email] wrote:
>
>I hope soon to propose documentation for creating publish source GitHub repositories. If time and energy allow, I'll try to follow it up with a stab at a "Building Erlang on Ubuntu" draft inspired by Fred Hebert's suggestion.
>
>I need to understand how to put such documents on the web, so I'll do so as time permits.
>

You can start by putting a document on github, which might make it
easier for people to send contributions and add content, possibly steps
on other frameworks.

That might be the lowest overhead solution at least :)


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Documentation -- what I ran into when I installed kerl

empro2
In reply to this post by Lloyd R. Prentice-2
On Wed, 21 Nov 2018 15:02:34 -0500 (EST)
[hidden email] wrote:

> And I would add, "and where a noobie can all too easily
> flounder around lost at sea."

The one big asset newbies bring is: they do not know what
is meant.

Those who know how it works often write for those who
already know anyway (and only need something to remind
them), but their asset is: they know how it works.

By the time people have kept track of enough of the things
they need to know to write their own, additional, "how to",
they have lost (too?) much of their original asset by
gaining some of the other.

Having been suggested to use git (pull requests) to
contribute to the Erlang documentation has made me
wonder what the best (or a good) way to combine these
two assets could be. Well, I wanted, or needed, or wanted to
because I needed to learn git anyway, but is that an
efficient way to rephrase some distractingly strange phrase
in the docs? or to correct some typo?

And I will not start to write up my own documentation on
mod_esi, httpd, inets, applications and application
controllers, mnesia, match specs, Emacs lisp, git, github,
JIRA Agile and all the other things I need to know (and
those I am too curious to skip - and that does not kill the
cat only ... ;-). That is too much work for a single person,
even more so as it is bound to be partially redundant, and:
were it not so inefficient, I would hang myself every time
I get confused by a piece of my own documentation ;-)

Might not be a silver bullet, but as documentation needs to
be quickly accessible (for the authors especially!) a wiki
might serve well. But it is not that simple and I intend to
start some separate thread about more efficient
contribution. Hope I keep that intention beyond getting
some practice with git, avoiding a github account and a
JIRA (or Agile?) account, but I am not yet sure that I know
what I am doing and I want to avoid bothering people on
this list too much.

But I might be already by straying too far from the
topic ...

Taking from the tone of some previous e-mails in this
thread it might not hurt to point out that criticism can be
a way of appreciating the loads of good and hard work that
went into Erlang, kerl, git, ..., and their documentation
too. Criticising can take a lot of time and who would want
to waste time on rubbish :-)

Intimidated by kerl's power I realised that I did not
really need to serve different versions of Erlang/OTP nor to
keep up to date (yet?) and was fine with something like
    $ sudo apt-get install erlang

I know kerl is there should I need it, and I hope it will
then be easy to contribute to its documentation :-)

Michael

--

“Even after a thousand explanations a fool is no wiser,
whereas someone intelligent requires only one fourth of
these.”

        – from the Mahābhārata (महाभारत)



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Documentation -- what I ran into when I installed kerl

Jesper Louis Andersen-2
In reply to this post by Lloyd R. Prentice-2
On Tue, Nov 20, 2018 at 11:37 PM <[hidden email]> wrote:

  

2. When I executed $ kerl build 21.1 I again ran into failure-- needed ncurses library. Took 15 minutes to find the right package name, but the solution was:

 

~$ sudo apt-get install libncurses-dev

 


Some times, you can optimize this step:

sudo apt-get build-dep erlang

This will find the necessary build dependencies for the target package and install them. Many package managers have a command which does something to the same effect. This avoids the feedback loop of adding a missing build dependency only to see the build fail with a new missing package. And it also avoids having to figure out the name of the package in the first place. Erlang is a bit finicky because if it cannot find certain packages, it will still build, but without that support. The crypto package is dependent on an (Open)SSL library; often a culprit which leaves your Erlang installation in a limbo state in which no cryptographic code will run[0]

[0] Your bitcoins will be fiiiine though :)


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Documentation -- what I ran into when I installed kerl

Lloyd R. Prentice-2
Excellent tip!

Thanks, Jesper.

Lloyd

Sent from my iPad

On Nov 26, 2018, at 10:17 AM, Jesper Louis Andersen <[hidden email]> wrote:

On Tue, Nov 20, 2018 at 11:37 PM <[hidden email]> wrote:

  

2. When I executed $ kerl build 21.1 I again ran into failure-- needed ncurses library. Took 15 minutes to find the right package name, but the solution was:

 

~$ sudo apt-get install libncurses-dev

 


Some times, you can optimize this step:

sudo apt-get build-dep erlang

This will find the necessary build dependencies for the target package and install them. Many package managers have a command which does something to the same effect. This avoids the feedback loop of adding a missing build dependency only to see the build fail with a new missing package. And it also avoids having to figure out the name of the package in the first place. Erlang is a bit finicky because if it cannot find certain packages, it will still build, but without that support. The crypto package is dependent on an (Open)SSL library; often a culprit which leaves your Erlang installation in a limbo state in which no cryptographic code will run[0]

[0] Your bitcoins will be fiiiine though :)


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions