Re: proposal to fork the build-tools projects
From: Dan Kegel <[EMAIL PROTECTED]> Date: Mon, 21 Oct 2002 10:51:51 -0700 You think the world is ready for Guile? guile is not ready for the world. current install practice spews .la and .so files all over $libdir and uses an internal "bugfixed" copy of libltdl (if my reading of the cvs commit logs is accurate). this is in the grand solipsistic tradition of guile development, which bletcherous nature (at present) is addressed by the OP's analysis. probably other projects suffer from similar manglement, which is why the analysis is relevant. that discussion does not continue is not surprising given that most programmers w/ available cycles to burn have difficulty smashing their ego in the name of Quality. although my response was another way of pointing this out, i think that regardless of human predilections the rise of software accountability, as implemented by OP's change proposal or otherwise, is inevitable. source code is just artifact, bits on a hard drive, a sentence w/o context. if you trust the speaker, fine. if you don't, where does that leave you? i'll tell you: in the same boat as those who trust their pensions to another whose methods are not known, in the same boat as those who trust their rights to another whose methods are not known, and so on. the suffering of people through ignorance is historic. knowing the method of software production is one way (perhaps the only way) of building trust in it. towards this, the auto* and like-minded tools should strive, and in doing so, help the people using those tools find courage in improving themselves and society at large. Can I have some of what you're smoking, please? :-) i ran out a while back, sorry. thi
Re: proposal to fork the build-tools projects
> It could be that we should tell people to use Bash to build > GNU packages if their native shells have trouble handling the > job. That would be a smaller change and perhaps worth doing. How is `bash' built? >> You need to be able to compile the bootstrap packages in minimal >> environments, in order to get a very basic GNU environment. > I don't think we should do this at all. The smallest version of the > GNU system need not be "minimal", and making it so would be extra > work, so we should not. Well, then I think you agree with me and you should conclude that forking as I've suggested is the right thing to do. GNU ALREADY has this property that you dislike wasting effort on, and it does result in wasted effort (it appears to me). My proposal to fork the build tools is a way to eliminate the wasted effort without purturbing the useful structure it currently preseerves. The core *utils package and the compiler are already maintained with relatively strict portability requirements (for example, that they can be compiled with a variety of compilers, shells, and implementations of make). The maintainers have been doing this for years, and it's very valuable. That's _not_ wasted work -- it's how people are able to migrate to the wider world of GNU software. However, those portability requirements from the core packages turn into requirements for the build tools (the auto* tools especially). So, for example, (I gather from this list), there are parts of autoconf that can't get away from m4 and that can't use shell functions. There are parts of automake that can't assume the featuers of (extremely portable) GNU make. _That_ is the source of the extra work that can be eliminated. It turns into extra work because of all the other apps people are working on that put demands on the build tools. Any effort put into making the build tools work better for those apps has to pay an "effort tax" by designing a solution that doesn't disturb the portability of *utils. The way to _save_ work is to stabilize a fork of the auto* tools for the *utils and compiler, and create an easier-to-change fork for everything else. The easier-to-change fork can, at least, assume it's running with a good shell and the *utils. -t
Re: proposal to fork the build-tools projects
You need to be able to compile the bootstrap packages in minimal environments, in order to get a very basic GNU environment. I don't think we should do this at all. The smallest version of the GNU system need not be "minimal", and making it so would be extra work, so we should not. Because autoconf was not designed with maintaining complete systems in mind, every single distribution adds a "package manager" whose job is to audit what is installed and manage dependencies among installed packages. Autoconf is not supposed to be a package manager; it is not meant to decide which packages to install, only to decide how to build a given package. Even just the awkwardness of using m4 to work-around broken shells makes hacking autoconf less than pleasant. It could be that we should tell people to use Bash to build GNU packages if their native shells have trouble handling the job. That would be a smaller change and perhaps worth doing.
Re: proposal to fork the build-tools projects
Thien-Thi Nguyen wrote: sounds about right -- finding the appropriate mux point to pinch is indeed the first step towards sanity. if you get funding, give me a buzz. otherwise, i will continue to work w/ (old) librx and approach the problem from the guile perspective. (e.g., below is lex.test w/ a simple shell-lexer spec. probably guile will be able to do a busybox-like sumo move on the auto* tools by end of 1.4.x.) You think the world is ready for Guile? Can I have some of what you're smoking, please? :-) - Dan
AWARD NOTIFICATION
WERKEN BIJ DE LOTTO, 41132, NL-1007 DB AMSTERDAM, THE NETHERLANDS. FROM: THE DESK OF THE DIRECTOR PROMOTIONS, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: WBL/67-B773524441 ATTN: AWARD NOTIFICATION; FINAL NOTICE We are pleased to inform you of the announcement today, 21ST OCTOBER. 2002, of winners of the WERKEN BIJ DE LOTTO/ INTERNATIONAL PROGRAMS held on 19TH MAY 2002. You / your company, attached to ticket number 013-2316-2002-477, with serial number A025-09 drew the lucky numbers 37-13-34-85-56-42, and consequently won in category C. You have therefore been approved for a lump sum pay out of US$1,500,000.00 in cash credited to file REF NO. REF: WBL/67-B773524441. This is from total prize money of US$22,500,000.00 shared among the fifteen international winners in the category C. All participants were selected through a computer ballot system drawn from 30,000 names from Australia, New Zealand, America, Asia, Europe,USA and North America as part our International Promotions Program, which is conducted annually. CONGRATULATIONS! Your fund is now deposited with a Finance and Security House and insured in your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly from public notice until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of you prize, you will participate in our end of year high stakes US$1.3 billion International lotto. To begin your claim, please contact your claims officer immediately: JANSEN DAVIS FOREIGN SERVICE MANAGER, EUROLITE BV, PHONE:31-619676795 TEL/FAX: 31 205241590 FAX: 31 205248221 EMAIL:[EMAIL PROTECTED] For due processing and remittance of your prize money to a designated account of your choice. Remember, you must contact your claims officer not later than OCTOBER 27th, 2002. After this date, all funds will be returned as unclaimed. All correspondences to Mr. Jansen Davis,either by fax or email, should have this email sent along with it and also, your email address to which this email is sent, should be clearly and boldly written in your response. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference number in every one of your correspondences with your officer. Furthermore, should there be any change of your address, do inform your claims officer as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions program. Sincerely, THE DIRECTOR PROMOTIONS, WERKEN BIJ DE LOTTO. www.werken-bij-delotto.net N.B. Any breach of confidentiality on the part of the winners will result to disqualification. Please do not reply this mail.
Para Kazandıran Yeni Arama Motorunuz
Title: DUYURU www.arama.cc Soru ve sorunlar için e-mail : [EMAIL PROTECTED]
Re: include files and statically linked libraries
On Sun, 2002-10-20 at 14:40, Tom Tromey wrote: > Does libghttp have its own configure script? Yes > If so it is probably even cleaner to run that. Put this in > configure.in: > > AC_CONFIG_SUBDIRS(libghttp-1.0.9-mod) > Where does this go in the configure.in file? Above the AC_OUTPUT command? From what I have read there has to be an order to the script, so I want to make sure I put it in the right place > Then put this in your Makefile.am: > > SUBDIRS = libghttp-1.0.9-mod > I assume this goes at the top of the Makefile.am file? Thanks for your help on this. -- Eric Anderson
Re: include files and statically linked libraries
On Sun, 2002-10-20 at 14:40, Tom Tromey wrote: > Why your approach failed, I don't know. I assume you re-ran autoconf, > automake, and configure? OK, I have done things as you have suggested, but I am still stuck at that error. I have narrowed it down to the fact that when I put the SUBDIRS = libghttp-1.0.9-mod line in the top of Makefile.am the error is caused. For reference the error is: Makefile:225: *** missing separator. Stop. and line 225 of the Makefile is: @SET_MAKE@ I stuck the terms "@SET_MAKE@" and "missing separator" into google and found a couple of other people reporting this, but no solution is ever listed. I checked both the webs and Google Groups. No solution. Any help is greatly appreciated. -- Eric Anderson
Re: FYI: same library installed several times in same directory (PR/350)
> Harlan> Just to ask, what is the problem if the same library is > Harlan> installed in two different places? > > Automake produces only one rule to link the library, and > therefore doesn't know how to set `-rpath' correctly. See > PR/285. So what is the problem with: if COND1 lib_LTLIBRARIES = liba.la else if COND2 pkglib_LTLIBRARIES = liba.la endif endif I'd hate to have to hack around this problem using something like: Makefile.am: noinst_LTLIBRARIES = liba.la if COND1 SUBDIRS = . cond1 else if COND2 SUBDIRS = . cond2 endif cond1/Makefile.am: lib_LTLIBRARIES = ../liba.la cond2/Makefile.am pkglib_LTLIBRARIES = ../liba.la (assuming I can get this hack to work). H
