Re: gEDA-dev: Re: [Gnucap-devel] Gnucap docs build failure on FC5(and other places)

[Russell Shaw <rjshaw-at-NOSPAMnetspace_dot_net_dot_au>]

Stuart Brorson wrote:
>> Generalizing, the problem is *dependencies*.  For end users, one of
>> gEDA's bigger problems is the number of dependences.  Distros are all
>> over the map in terms of what is bundled, what is not, what is
>> installed by default and what is not.  Many of the complaints we hear
>> from clueless newbies have to do with not being able to install
>> (either from CD, source, or whatever) since there are so many
>> dependecies.
>>
>> By making the build of any of the gEDA Suite packages
>> dependent not only upon various software libraries (for teh programs
>> themselves), but also upon the presence of documentation build tools,
>> the dependency problem is exacerbated.  My suggestion is that we
>> distribute the documentation targets for all gEDA programs -- not just
>> the Latex sources -- so that this dependency problem is removed.
> 
> 
> I'll expand on this point just a little more.
> 
> In distributing sofware, it makes sense to distribute the program
> itself as source code, since the target (binary object files) is very
> machine dependent.  That is, a binary compiled for x86 won't run on
> SPARC, but -- in principle -- both machines can use the same source
> code.  That is, we let the machine itself figure out how to binaries
> since the binaries depend very sensitively upon machine architecture. In 
> this case, we accept and deal with the dependency problem
> since the hassles of dealing with object binaries is large.
> 
> In the case of distributing documentation, however, it makes sense to
> distribute the targets (along with the source, if desired) since .pdf,
> dvi, html, etc is the same on my x86, my OSX, my SPARC, and my Windoze
> box.   Therefore, it's wiser from a distribution standpoint to
> eliminate the dependency problem and just distribute the targets.
> This eliminates a good chunk of the build problems we see in the
> field.

If you fill the package with PDFs, it'll get rejected or repackaged
by any decent Debian maintainer to have a separate documentation package.
With the current build problems, it's lucky to be accepted into any
distribution at all.

> As for the person who made the point that the problem was an autoconf
> issue:  If you would care to actually do some work and send a patch to
> fix the configure.ac file instead of proferring cheap advice, then I'd
> stand up and take notice.   Otherwise, you're just blowing easy
> advice out your @ss.  Tweaking the autotools so that they do the right
> thing in every case is a difficult job.  You'd know that if you tried
> to do some real implementation.

I'm too busy doing real code to go on that diversion. Look up AM_CONDITIONAL.


_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev