Re: [Gnome-devtools] Handling External Dependencies

[Martijn van Beers <martijn earthling net>]

On Wed, Apr 12, 2000 at 05:47:04PM -0700, Dave Camp wrote:
> 
> I'm reposting this here so we can get some discussion going.  I've
> already discussed this a bit with JP and Martijn, and there were some
> issues.  I won't bring them up right now, I'll let one of them handle
> that. :)

posting the log for archiving purposes

<LotR>  a problem you didn't address was the UI for this
<campd> yes
<campd> I thought about it, but the mail was already pretty long :)
<campd> For pre-existing libraries, you would just form a series of check-boxes:
<campd> [ ] Bonobo   The Bonobo Object Model
<campd> [ ] gnome-debug 
<campd> etc
<LotR>  yes, that's the easy part :)
<campd> yeah
<campd> :)
<campd> I can think of two ways to do the hard part.
<campd> When the user wants to create a new dependency (or add the information
        for a new backend to an existing dependency), one of two things could
        happen:
<campd> 1) Each backend could export a description of how the data in its
        particular <information> block should be formed, and a UI would be
        generated from this.
<campd> or 2) You simply ask the backend to create a dialog for editing
        dependencies.
<LotR>  hmm, 3) have them edit the file themselves
<campd> yes, that is possible too.
<campd> But you were asking about UI :)
<LotR>  another problem is that not everything is handled with just a simple
        macro in autoconf
<campd> I know
<campd> But I don't think there is *any* way to solve that.
<LotR>  well... I want to do more autoconf stuff than just library macros
<LotR>  setting LINGUAS comes to mind
<campd> Oh, yes
<campd> But that is not dependency related.
<campd> I'm just talking about dependencies, we can discuss other parts of
        autoconf later.
<LotR>  oh, ok
<LotR>  so, what do you think?
<jpr>   I think that it seems ok, but like LotR I worry about handling those
        messed up tests and things people have in existing files
<campd> Yeah
<campd> Well, the messed up tests are really the heart of the problem.
<campd> But for the life of me I can't figure out how to deal with them
        100% perfectly.
<campd> Except that the autoconf backend will need to read in the entire file
        and keep it intact, ignoring things it doesn't understand.
<campd> And perhaps there could be a "believe me, the dependency's check is
        hidden in there somewhere" option when including a dependency into the
        project.
<campd> I don't know
<jpr>   the regex's will have to carefully crafted to avoid problems as well
<campd> yes
<campd> In other words, don't let me do them.
<jpr>   maybe there can be per project meta-data that says "this is a custom
        provider of the *z* dependency"
<LotR>  oh, and we definitely want to handle if/then/else is some way
<LotR>  isn't sure how much of the current auto* dependency is actual dependency
        and how much is just perceived dependency because of terminology use
<jpr>   hmm, yes there conditional depencies
<jpr>   for instance, bonobo can depend on libgnorba or oaf
<campd> yes
<LotR>  conditional was the word I was looking for
<jpr>   anyhow, yes conditional dependencies - must be able to describe them
        in the xml dependency files
<campd> well, the configure.in part of conditional dependencies isn't really
        too hard.
<jpr>   campd: the xml format needs to be able it properly though
<campd> yeah
<campd> is thinking
<jpr>   campd: there are a couple of ways to handle the conditional dependencies
        in the xml file
<jpr>   1. use a provides to interface (like rpms or debs do)
<jpr>   2. use a "one of" structure
<jpr>   ie
<jpr>   <one of><dependency>libgnorba</><dependency>oaf</></one of>
<jpr>   (use better words of course)
<campd> both are fine
<jpr>   I think two will be easier
<campd> I was actually thinking of a slightly different problem.
<campd> Like the use of libghttp in the panel, where the dependency doesn't
        necessarily have to be there for the project.
<campd> s/panel/panel applets/
<jpr>   campd: you mean that where if it isn't there, the build still occurs but
        in a different way?
<campd> yeah
<jpr>   that is stickier
<LotR>  noone happens to know a project that uses imake instead of auto* right?
<campd> You know, maybe we should all just spend a week in the woods with
        printouts of Makefile.am's and configure.in's from a wide range of
        projects... :)
<dirk>  LotR: you do mean a gnome related project, right? ;-)
<jpr>   heh
<jpr>   campd: not here though, its snowing!
<LotR>  dirk: no
<jpr>   LotR: doesn't X use it?
<campd> jpr: I dunno, I've heard some people have enlightening experiences when
        near death.
<LotR>  ugh, X is a bit too big for my HD capacity right now
<dirk>  LotR: almost all applications at ftp.x.org use imake... so does X itself
<dirk>  and Motif too
<campd> Just so that you guys know, I refuse to even attempt making sense of X's
        makefiles in gnome-build...
<campd> I can't even do it myself.
<dirk>  you do mean the Imakefiles, right?
<LotR>  goes look at imake stuff to see how similar the concepts are
<dirk>  the makefiles themselves are hopeless, as are the auto* makefiles
<campd> dirk: yeah, the imakefiles
<dirk>  campd: they're not that complicated. It depends on what you used first:
        auto* or Imakefiles. I had less troubles with Imakefiles at first
<dirk>  is a member of XFree so he feels obliged to defend imake
<campd> We also might want to look at whatever comes out of Software
        Carpentry...
<dirk>  what is SOftware Carpentry?
<campd> dirk: http://www.software-carpentry.com, it's a contest to write a
        better set of tools than autoconf/automake, among other things.
<dirk>  LotR: you'd be better off getting some applications in /contrib
<campd> IIRC raph was going to do an SC entry.
<dirk>  ah yes, I remember now
<LotR>  dirk: hmm, how about docs for Imakefile syntax?
<dirk>  LotR: man imake, and there should be some extra docs in the imake
        distribution. I'll see if I can find anything
<LotR>  [martijn khazad-dum xearth-1.1]$ man imake
<LotR>  No manual entry for imake
<dirk>  Reformatting imake(1x), please wait...
<dirk>  LotR: you need a better installation :)
<LotR>  hmm, looks like imake is much lower level than automake
<dirk>  it requires more user intervention, yes.
<LotR>  this sucks :(
<LotR>  I was hoping the system would be more similar
<dirk>  not exactly. it doesn't do all those fancy automated checks
<dirk>  and it requires a very well installed system
<dirk>  in fact, you'll find that on most systems imake doesn't even work
        properly
<LotR>  of course, we could write a bunch of #defines so it's similar to
        automake
<dirk>  why do you want imake compatibility anyway?
<LotR>  I wonder if there's another build system that's more like automake
<LotR>  dirk: I don't. I want auto* independance :)
<LotR>  dirk: which means imake compatibility if it's the only other build
        system :)
<campd> LotR: Making it look like auto* doesn't make it independent.
<dirk>  I don't think there's a reasonable alternative
<campd> LotR: What about, for example, Java's build system?
<campd> Or people that want to migrate from CodeWarrior?
<LotR>  campd: that's at the same level as gcc, not auto*
<LotR>  isn't it?
<LotR>  hmm, codewarrior. is that free (beer)?
<dirk>  no
<campd> Java's build system?  Not really, it handles dependencies and stuff
        itself.
<campd> (and much differently than auto*)
<dirk>  codewarrior is definately not free
<campd> LotR: (I'm referring to Sun's java, not gjc or whatever)
<LotR>  well, I'm not interested in providing a migration path from non-free
        stuff, since I'd need to pay for it to be able to see how it works
<campd> But a migration path is essential!  Even if we don't want to do it
        ourselves, we should support it.
<LotR>  yes.
<campd> Remeber, we are here, in part, to promote free software.
<LotR>  but we need to find some build system other than auto* to see which
        concepts we can use
<dirk>  I've got a copy of codewarrior somewhere
<dirk>  I've never used it though, so I'm not sure what kind of build system it
        uses
<LotR>  otherwise you might as well be completely auto* dependant, and have
        the parsers figure out to emulate how to get it right
<LotR>  dirk: could you take a look for us?
<dirk>  I'll try to find it. It's at work, so I can't look before Monday
<LotR>  fears it uses binary build files
<campd> LotR: I have enough experience with VC++ and Java that I know something
        (not a whole lot, but something) about what changes between build
        environments.
<LotR>  dirk: there's no rush!
<dirk>  campd: vc++ just uses makefiles
<campd> dirk: not really
<dirk>  LotR: ok. I'll check it out and report here. or on the devel-app
        mailing list if it ever gets set up
<LotR>  dirk: krissy knows our email addy's, so..
<campd> goddamnit I can't eat until I find that number!
<dirk>  campd: sure. it only uses precompiled header files and normal makefiles
<campd> dirk: VC6?  You have to tell it to create makefiles for you, and if you
        do they are slightly different than what is done if you click 'build'.
<campd> dirk: That isn't really the point, though.  The thing is, it handles
        dependencies and stores data much differently from autoconf/automake.
<LotR>  campd: ok, so you write up something about vc++ and java's way
<dirk>  campd: they have workspaces and project files, but they're nothing
        special. I'm not sure how they do dependencies, but I figure they use
        the output of the compiler
<campd> dirk: No, it isn't anything special.  But it is a different build
        system from autoconf/automake. 
<campd> anyway
<dirk>  campd: but it's even more primitive than imake
<campd> dirk: yes, it is
<campd> but I don't agree with LotR's idea of making everything work just like
        automake so that we don't have to think about our design now.
<dirk>  We have our own build system. Anyone interested in the specs of it? ;-)
<dirk>  (we == company)
<dirk>  It's actually a layer on top of imake
<LotR> campd: I'm not saying we should make everything look like auto*, but if
       they aren't of a comparable level of abstraction, it's nuts to try and
       come up with an interface that works for both
<LotR>  dirk: yes, that'd probably be closer to what I'm looking for
<LotR>  dirk: so it would be nice if someone made a comparison with auto*
<dirk>  LotR: I'll see what I can dig up. It doesn't do dependencies though,
        clearmake takes care of that
<LotR>  either you, or someone you send the spec to ;)
<campd> finds his pin number and tries to decide where to eat.
<dirk>  I haven't used automake that much...
<LotR>  dirk: with dependencies, we mean dependencies on the autoconf level,
        not dependencies on the automake level
<dirk>  LotR: example?
<LotR>  dirk: gnumeric depending on bonobo
<dirk>  LotR: ah. ok, I can do that easily. maybe not a comparison, but at
        least a description with examples.
<LotR>  dirk: so there's a AM_PATH_BONOBO in gnumeric's configure.in
<LotR>  dirk: that would be very cool
<dirk>  LotR: we use build files. every component has a build file, and other
        components refer to the build file of other components they use.
<dirk>  LotR: we have a kind of tutorial project, which also details libraries
        and stuff. I'll pack it up and send it over.
<LotR>  anything else that needs discussing?
<dirk>  no. the more we discuss, the more work for me :)