Re: [crosstool-NG] Design discussion

[Ladislav Michl <ladis at linux-mips dot org>]

On Wed, Apr 08, 2009 at 08:13:31PM -0500, Rob Landley wrote:
> On Wednesday 08 April 2009 05:22:09 Ladislav Michl wrote:
> > You do not need install PTXdist anywhere to start using it.
> 
> Uh-huh.  Starting from a fresh tarball...

I didn't do that in last few years, so perhaps there is something wrong with
tarballs...

>   $ make menuconfig
>   make: *** No rule to make target `menuconfig'.  Stop.
> 
>   $ bin/ptxdist menuconfig
>   ptxdist: error: PTXdist in /home/landley/ptxdist-1.0.2 is not built.

~/src/ptxdist-trunk$ grep AC_INIT configure.ac
AC_INIT([ptxdist],[1.99.svn],[ptxdist@pengutronix.de])

...ah here it is, seems version differs and indeed there are some newer
tarballs: http://www.pengutronix.de/software/ptxdist/download/v1.99/
Note that 1.0.2 is maintenance release of 2 years old stuff...

>   $ make
>   make: *** No targets specified and no makefile found.  Stop.
> 
>   $ ./configure
>   checking for ptxdist patches... yes
>   checking for gcc... gcc
>   ...
>   ptxdist version 1.0.2 configured.
>   Using '/usr/local' for installation prefix.
> 
>   # Try crosstool-ng's way?
> 
>   $ ./configure --local
>   configure: error: unrecognized option: --local
>   Try `./configure --help' for more information
> 
> It seems more accurate to say there might be a non-obvious workaround for the 
> need to install it before using it.

~/src/ptxdist-trunk$ ./configure && make
~/src/ptxdist-trunk$ cd ../ptx-test/
~/src/ptx-test$ ../ptxdist-trunk/bin/ptxdist menuconfig

Now it will bitch at you again about selected platform config etc...
So those two years do not represent any progress for the point you are
trying to make. Shame ;-)

> > Install part is 
> > optional just in case you want to distribute it as binary tarball to your
> > colleagues
> 
> Isn't what we downloaded already a tarball?  The only "binary" part seems to 
> be the kconfig binaries...
> 
> > or make (for example) debian package. However I have to admit 
> > that it is non obvious. PTXdist's kconfig is hacked a bit to handle
> > dependencies, so if you want to express openssh dependency on openssl you
> > do so in Kconfig file only.
> 
> Doesn't kconfig normally track and enforce dependencies?  I thought that was 
> one of its main functions...

...and still is, I just didn't express it clear. If feature FOO depends on BAR,
you compile both and link them together. No matter which one gets compiled first.
Now when program FOO depends on library BAR you need to compile that library
first to let FOO link against it which is something 'plain' kconfing does not
handle.

> > The 'ptxdist' script could probably do that as 
> > well, but unless you hack on PTXdist itself you are expected to run
> > ./configure && make only once.
[snip]
> I'm just wondering where this "source code should be installed before you can 
> compile it, just extracting a tarball isn't good enough, you need to run 
> configure twice and make twice" meme came from.  I still don't understand the 
> supposed advantage...

I'm not going to advocate this design decision (as I can live with that). From
developers point of view it ensures a user runs expected environment. Try to
look at it from this perspective. You have configure script and it is there to
check your environment, so once it is already there as ordinary user you would
expect it will also produce some makefile and that make file will so something.
And it really does. Could it be done different way? Yes it could, just this one
is easy to implement the goal: check user environment. And it does exactly
this.  Compiling mconf is there just to save one probably irrelevant step when
running ptxdist script.  Once prerequisities list gets short enough to contain
only stuff everyone is supposed to have, then it will probably turn to be
easier to dump all this configure thing away, do it 'kernel way' and live
happily ever after.  Um, didn't I say I'm not going to advocate it? (My
point of view may differ from PTXdist main developers)

[snip]
> > Anyway, this is starting to be off topic, so in case you want anything to
> > be improved (and you did few valid points here), fell free to start another
> > thread called for example "Why PTXdist sucks" (such a subjects tend to
> > attract attention) to prevent this one from pollution.
> 
> Oh I think all modern software sucks.  My monday blog entry was, just for 
> exercise, why my _own_ build system sucks:
> 
> http://landley.net/notes.html#06-04-2009
> 
> (And that's by no means even close to a complete list, that was just off the 
> top of my head in the five minutes I was willing to spend typing about it.)
[snip]
> I'm trying to ask the "Do we really _need_ fins?  What about gas mileage?  Is 
> lead really _necessary_ in gasoline?" type questions.  Even if everything 
> (including the stuff I've written) currently gets this sort of thing wrong, 
> it should still be possible to do _better_...

I'm wondering, why you (a computer guys) are always trying to compare software
development to automotive industry without having any deeper clue about it.
Pretty please leave away those analogies as they are not completly analogic
and do not serve any real purpose.

Thank you,
	ladis

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