Re: cd crosstool-ng ; make menuconfig

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Andy, All,

On Tuesday 31 May 2011 22:52:47 ANDY KENNEDY wrote:
> Consider the commands:
> 
> cd <path to>/crosstool-ng
> make menuconfig
> 
> Now, this gives an error.  I understand why this is designed to give an
> error, but I don't understand why this is desirable behavior.  We _can_
> produce the same results by adding something along the lines of:
> 
> %:
>         @$(DESTDIR)$(BINDIR)/ct-ng $@
> 
> to the bottom of the Makefile.  Doing so would allow one to run all
> unknown targets (in the parent Makefile) through the ct-ng Makefile.
> 
> Would this be a valid fix to this annoyance?

Not really. I do not consider this as an anoyance. Let me explain...
Let's compare how virtually all programs are processed.

First, you download the source for the program: wget, curl, git, whatever,
you name it. And you extract the source code if you got a tarball or any
other archive.

Second, you configure the program, with the usual ./configure step. At this
time, you have to tell configure where you want the program to run from,
this is what is traditionally called the prefix. Optionally, you also set a
few options, such as where to find some required components, using --with-*,
and whether you want to --enable or --disable some features (there is none
in crosstool-NG, for now).

Third, you build the program. This is done running 'make'. For most
programs, it implies calling the compiler and the linker to produce a binary
executable, customised using the options passed to ./configure. For
crosstool-NG, this involves inserting the proper paths in the ct-ng script,
so that it can find its dependent files.

Fourth, you install the program, using 'make install'. This copies the
program files, executables and ressources, into the final place.

Fith, you can get rid of the source code directory altogether.
And you are finally set-up and running, you can use your program.

Now, let's take gcc and the linux kernel for example, and compare with
crosstool-NG ( assuming /bin is in the PATH, and --prefix=/ ):

             gcc               Linux kernel               crosstool-NG
configure    ./configure       make menuconfig            ./configure
build        make              make                       make
install      make install      make {modules_,}install    make install
use          gcc               boot it (grub/kexec/...)   ct-ng

Of course, the comparison with the Linux kernel stops here. But for gcc,
we can continue the comparison. We can create some /source/ to be (kind of)
'interpreted':

                   gcc                     crosstool-NG
editor             vi script               ct-ng menuconfig
execute 'script'   gcc 'script' -o 'exe'   ct-ng build
use the result     ./exe                   /your-toolchain/tuple-{gcc,ld,...}

Yes, crosstool-NG provides its own editor [0]. Yes, it is very, very similar
to the configuration scheme used by the Linux kernel. But really, this is
to be interpreted only as the editor for crosstool-NG source. Yes, you
could probably use any other editor, such as vi, emacs, eclipse... to create
a source for crosstool-NG. The syntax is very, very simple, but the number
of keywords if just overwhelming, and the grammar very complex, so the
built-in editor is a very simple way to create the source.


Now, about the 'ct-ng' front-end. 'ct-ng' is a script. It is written in
the Makefile language, but it is a script. Let's compare with shell and
Python, this time. You have a program that is written in python, another
one written in shell, and crosstool-NG, written in Makefile. They are
all scripts, just using different interpreters:

                   Python               shell            Makefile
execute program    python -c 'program'  sh -c 'program'  make -f 'program'

Of course, this is not very convenient, so we have the standard way of
telling that an executable is a script, and that the kernel should try to
execute it through an interpreter: the sha-bang '#!'. So now, whatever
scripting language the program is written in, one can execute it simply by
calling its executable (provided it is in the PATH):

                   Python               shell            Makefile
execute program    program              program          program


Yes, writing the front-end as a Makefile script is probably not the best
move I ever did. But that's the way it is. Now just imagine that the
whole of crosstool-NG was written in C. How would you expect to use the
front-end? Surely, you'd expect the traditional dance:
  ./configure && make && make install

before you could ever use it. Just expect the same from crosstool-NG.
That it is written in Makefile does not change this.


Finally, a note about './configure --local'. Place yourself as an
*end-user* perspective. You would not use a program directly from its
source directory?

When you use gcc, do you run it from its source tree? When you use bash, do
you add its source dir in the PATH? When you *run* the kernel, don't you
install it first into /boot (or whatever for your platform)?

The same goes for crosstool-NG. You would normally install it before you
would use it. As an *end-user*.

But while developing crosstool-NG, it can be convenient to just run from
the source dir, as a way to quickly test your changes, without impacting
an existing installation. That's what the --local flag is for: for a
crosstool-NG developper to quickly test his/her changes. It is not meant
as a way to traditionaly use crosstool-NG.

Also, imagine a distribution that wants to package crosstool-NG. The
usual way is to go with the following dance:
  ./configure --prefix=/usr
  make
  make DESTDIR=/path/to/staging install

and then properly package the content of /path/to/staging. Then, users of
that distro would just install the crosstool-NG package, and call 'ct-ng'
as they would call 'gcc', 'bash', 'python', 'bc', 'find', whatever...


Globally, the core of the problem (if problem there is!) is just caused
by the menuconfig. People are used to run 'make menuconfig' in the source
dir of the Linux kernel. Where the Linux kernel uses menuconfig to
_configure_ the kernel, crosstool-NG uses menuconfig to _edit_ the source
for crosstool-NG. I agree this can be confusing at times.


This is a long rant, indeed, and I apologise for such a looong mail.
I should probably pass this whole rant through a smoothing filter, and
put it in the docs/ directory. Most probably, yes.

Regards,
Yann E. MORIN.

[0] In the goold old days, I discovered programing with Pascal, under DOS.
The Pascal implementation I was using was a DOS program that had its own
editor for the source code, and means to compile, and run, the program
currently loaded in the editor. There was no other way to compile, except
by first loading a program into the editor. There was no way to call the
Pascal compiler from the command line.  I could also edit the program from
an external editor, but then I would loose the (poor) completion and (poor)
syntax highlighting, and compilation would anyway force me to quit that
external editor and reload the program into the Pascal editor when I wanted
to compile it.Of course, once a program was compiled, a DOS binary
executable was available, and I could run it from the command line, as well
as from the editor. This is not very different than what crosstool-NG does,
in the end.
YEM.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq