[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Monday 07 February 2005 12:38 am, you wrote:
You're right in that after using a "one click" RPM install that trying to get things to compile from source is a much deeper issue. The only point I would make is that when I was programming (a long time ago admittedly) in BBC BASIC for A Level we were taught to assume the reader of all documentation knew nothing. I guess I have come to expect that myself of documentation written by others.
That cannot be achieved - you always start somewhere. The documentation you refer to still assumes: 1. The user can read. 2. The user can read English. 3. The user knows how to obtain the documentation itself. It's all about starting points. There is no need to repeat that level of documentation in every single source code tarball, you have to assume a basic knowledge or you end up making every tarball too large to download - as well as irritating those who have that knowledge already. No, that stuff needs to go in other locations that are updated separately and which can answer the general questions. The documentation inside a tarball MUST be specific to that source code. There are websites dedicated to gcc, automake, autoconf, packages, project distributions, CVS itself and lots of other areas essential to working within a source code tree.
I wasn't actually talking about merging the processes, simply warning the user (or reminding.. even experts forget sometimes) at the first hurdle that they should/may need to be root if they want to complete configuration. However, point taken.
I know, the problem with your suggestion is that it's outside the realm of the project itself. Whether /usr/local/ is writable by the current user is not determined by the code, it is determined by the user (via root access). As such, it falls under the remit of 'stuff most people doing this should already know'. You can, by all means, write a simple bash script that runs ./configure make make check make install but this doesn't achieve the objective of simplification because other users will need to edit this file to supply the options they need for their build environment. I may add some content to the Wiki about development and what you should know before dealing with source code. Depends how much time I can allocate.
They are (unless make install as root gave any errors), just not configured probably. You're unlikely to have a GUI to configure this, it'll all be by editing config files by hand.Problem there is I have no clue what the config files are or what they expect of me.
Now that's something that the project documentation can and should provide. Try checking the compiled tree for manpages, txt files, html files. If that fails, join the project mailing list and ask them. Problems within the package itself are going to be specific to that project - just be sure that you know what is wrong and that you've read up on how these things work. Project teams are v.busy people and won't appreciate criticism or queries that bely a lack of understanding of the problems.
It probably contributed to your problems that the package system is so smooth - CVS came as a nasty shock.I wasn't aware it was CVS! :) Shows how new I am to source installations. I guess source/CVS are interchangeable terms?
Almost, I guess some people do compile programs from the source package available from their distribution but that originally came from CVS and most people know that this code is old - all the new features (and a few new bugs) are in the latest development code and that comes via updated CVS. You'd only look at the source for the current package if there was a problem with installing that package. Only once have I needed to look at the source code for a specific version of a program installed on my system - and that was because the CVS was unavailable at the time. To be precise, source code is just that - CVS is actually the tool that provides the means of delivering and updating source code that is shared between developers. That's key: CVS is intended for developers - people who already know how to write in whichever language(s) are required for the project, people who have learnt elsewhere how to build and modify programs from source code. The biggest problem for project teams in dealing with bug reports is checking if the bug has already been fixed in CVS. That's why bugs that cannot be reproduced will be ignored - there is every reason to think that an update made after release has already fixed the bug.
Do you think that the gap between the two is a tad steep? I feel that you either take the newbie route of Packages
Packages are not just for newbies - very few people outside Gentoo will compile all their existing software from source. Fewer still will actually get involved in more than a handful of projects and gain any real understanding of the code itself. Developers need packages too - I have to have pre-configured libraries and compiler tools, communication software and development environment tools.
, or go straight to Expert level with CVS.
It depends on the package. In general, the jump is best handled by the user looking at the CVS for a small or familiar project where their experience with the program will flesh out the code and provide meaning. But yes, there is no denying that the jump from binary package to source code tarball is large. It's comparable with going from a Windows installation wizard to a DevStudio project that you are expected to load and compile yourself. First, you need to get use to the environment - whether DevStudio or gcc.
There seems no middle ground for the likes of me, who know something of the workings, and need more than the basic installation can give, but lack the experience to dive in headlong to the source code.
The gap has to be filled by the project support team, usually via a mailing list, and general support websites that focus on specific elements of the build process like gcc, autoconf and the CVS tool itself. CVS and source code are too specific to give more than very general pointers - which is precisely the problem with the usual INSTALL documentation, it's too general to be particularly useful.
I do value the help you and all of the list give me!
No problem. -- Neil Williams ============= http://www.dcglug.org.uk/ http://www.nosoftwarepatents.com/ http://sourceforge.net/projects/isbnsearch/ http://www.neil.williamsleesmill.me.uk/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
Attachment:
pgp00011.pgp
Description: PGP signature