Re: [dev] stali and the shipped compilers
On Thu, Jan 14, 2010 at 09:42:02PM +0100, pancake wrote: > I would prefer to drop gcc, glibc and all the shit from gnu. > > Tcc and dietlibc are usable solutions and maybe the code is not the best > one but at least is sane. > > Current toolchain is just to get a working version. I know that anselm > is really busy these days, like me.. This is the reason why some of > those projects are a bit stopped. > it would be interesting to see its outcome(s), has anyone looked at the packaging system for such a distribution? or will a bsd style tree of code/makefiles be adopted? > Is there any minimal and complete fortran implementation? > not as far as I know, I'm not aware of any minimal f77, f90 or f95 implementations. this is particularly true of f90 and f95 most of these implementations are commercial and I don't think I have seen any many free/opensource implementations worth using apart from gfortran. jimmy -- Jimmy Tang Trinity Centre for High Performance Computing, Lloyd Building, Trinity College Dublin, Dublin 2, Ireland. http://www.tchpc.tcd.ie/ | http://www.tchpc.tcd.ie/~jtang pgpDaWv8BJv73.pgp Description: PGP signature
Re: [dev] stali and the shipped compilers
2010/1/14 pancake : > I would prefer to drop gcc, glibc and all the shit from gnu. gcc is required unless one doesn't want to fuck with each source code unfortunately. Obviously glibc is only used when it cannot be avoided, otherwise my current preference is uclibc. > Tcc and dietlibc are usable solutions and maybe the code is not the best one > but at least is sane. dietlibc is awful. fefe is good at politics but not at coding. tcc is fine for small stuff. Cheers, Anselm
Re: [dev] stali and the shipped compilers
Jimmy Tang wrote: On Thu, Jan 14, 2010 at 09:42:02PM +0100, pancake wrote: I would prefer to drop gcc, glibc and all the shit from gnu. Tcc and dietlibc are usable solutions and maybe the code is not the best one but at least is sane. Current toolchain is just to get a working version. I know that anselm is really busy these days, like me.. This is the reason why some of those projects are a bit stopped. it would be interesting to see its outcome(s), has anyone looked at the packaging system for such a distribution? or will a bsd style tree of code/makefiles be adopted? there is no package system. I wrote slpm for fun, you can try it if you like hg clone http://hg.youterm.com/slpm
Re: [dev] stali and the shipped compilers
2010/1/15 Jimmy Tang : > On Thu, Jan 14, 2010 at 09:42:02PM +0100, pancake wrote: >> I would prefer to drop gcc, glibc and all the shit from gnu. >> >> Tcc and dietlibc are usable solutions and maybe the code is not the best >> one but at least is sane. >> >> Current toolchain is just to get a working version. I know that anselm >> is really busy these days, like me.. This is the reason why some of >> those projects are a bit stopped. >> > > it would be interesting to see its outcome(s), has anyone looked at the > packaging system for such a distribution? or will a bsd style tree of > code/makefiles be adopted? There is no need for a packaging system. Updates to the core stali parts will mainly be binary diffs for executables, so you only replace executables and potentially config files if needed. I see this as an advantage btw -- this also supports the way that programs can update/install themselves more easily. Cheers, Anselm
Re: [dev] stali and the shipped compilers
cd /; tar ztf package.tar.gz | xargs rm ;) 2010/1/15 Anselm R Garbe : > 2010/1/15 Jimmy Tang : >> On Thu, Jan 14, 2010 at 09:42:02PM +0100, pancake wrote: >>> I would prefer to drop gcc, glibc and all the shit from gnu. >>> >>> Tcc and dietlibc are usable solutions and maybe the code is not the best >>> one but at least is sane. >>> >>> Current toolchain is just to get a working version. I know that anselm >>> is really busy these days, like me.. This is the reason why some of >>> those projects are a bit stopped. >>> >> >> it would be interesting to see its outcome(s), has anyone looked at the >> packaging system for such a distribution? or will a bsd style tree of >> code/makefiles be adopted? > > There is no need for a packaging system. Updates to the core stali > parts will mainly be binary diffs for executables, so you only replace > executables and potentially config files if needed. I see this as an > advantage btw -- this also supports the way that programs can > update/install themselves more easily. > > Cheers, > Anselm > > -- http://gnuffy.chaotika.org - Real Community Distro
