Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On advice of Joerg Schilling and not knowing what 'star' was, I
> decided to install it for testing. Star uses a very unorthodox build
> and install approach so the person building it has very little control
> over what it does.
This is of course wrong:
- A lot of software uses an ancient build system introduced by Stallman
that is based on the ideas from the Open Source movement from the
1970s. This build system needs a lot of manual intervention because
is not very automated. It is also non-modular, uses multiple copies
of the same code, does not allow to simply add a software packet to
an existing tree without replicating code and results in
exteremely hard to maintain makefiles.
It does not support dependencies and by default overwrites compile
results from other platforms. This is why I call this system a
throw away compile environment: get tar archive -> unpack it ->
repeat: compile until you fount the right manual parameters ->
install -> trow everything away :-(
It is used by people who don't think globally....
- My build system started in 1992 (close to the time the RMS system
was introduced) and was inspired by the new ideas from Plan 9 from the
mid 1980s. It is based on new features from the plan 9 make
program (e.g. include other makefiles) and the SunPro make (1986)
pattern matching macro expansions.
It is highly modular, does not repeat code and works on more platforms
than the one mentioned above.
It automatically maintains dependencies and it allows to do
simultaneously compilations on all platforms if you NFS mount the
source. It allows the author to use the same environment than the
"user".
Simuilar approaches are used by FreeBSD, (*BSD), Solaris ON and
David Korn. The implementations found on FreeBSD, (*BSD), Solaris ON
are single platform (non-portable), the implementation from David Korn
is higly portable as the the Schily Makefilesystem. It is interesting
to see that David Korn (although he uses a different approach based
on a completely rewritten make program "nmake") arrives at nearly
identical "leaf makefiles", so it seems that there are common wishes
to simplify portability.
The most important advantage from my makefile system is that it needs _much_
less user input in order to work. This is why people may believe it gives less
control....in fact, it gives better control on the important parameters.
> Unfortunately I made the mistake of installing it under /usr/local
It seems that you did read the documentation and know how to get control on the
install location as the standard install location is /opt/schily.
> where it decided to remove the GNU tar I had installed there. Star
Well, if you make the mistake to install GNU tar as "tar" in a global
"dump yard" for software you need to be prepared other similar software
reuses the name "tar", in special if the other software (star) is closer
to the tar command line standard than GNU tar.
> does not support traditional tar command line syntax so it can't be
This is _definitely_ wrong: GNU tar does not correctly implement the
tar CLI standard while star does! If you have problems with scripts
that depend on the non-compliant GNU tar CLI, you get a problem.
I recommend to inform the authors of these scripts about their non-compliance.
> used with existing scripts. Performance testing showed that it was no
> more efficient than the 'gtar' which comes with Solaris. It seems
> that 'star' does not support an 'uninstall' target so now I am forced
> to manually remove it from my system.
It seems that you did not make real performance tests. I usually receive
thanks for the enhanced star performance. If your performance is already
limited by the background storage or by the filesystem, star of course cannot
help.....
Star typically needs 1/4 .. 1/3 of the CPU time needed by GNU tar ans it
uses two processes to do the work in parallel. If you found a case where
star is not faster than GNU tar andwhere the speed is not limited by the
filesystem or the I/O devices, this is a bug that will be fixed if you provide
the needed information to repeat it.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
