11 Jun 2000 star   » (Journeyer)

Ok it took me long enough to get this here, but I did add some more information about what you need to get nautilus compiled to the HACKING file. I know it is a lot of stuff to get out of CVS, but within two months it will be much less and will be fairly simple. I have started the project to minimize the number packages that need to come that way, but it will take some time, as I have other things to worry about. I also will need to coordinate a release of some modules as there are some bug fixes that nautilus needs from packages like ORBit.

Build Stuff

OK, todays topic on build stuff is what to do about packages!

One interesting problem with open source development is you may have to switch back and forth between three different ways of recieving code fairly frequently. The three majore forms are.

  • CVS
  • Release Tar Balls
  • System Package
Now what I want is to create sensible meta data for modules. We can call them module objects, that have all the properties you will need when refering to a module. Most likely the functions you will want are build(), get_code(), clean(), install(), remove_code(), update_code(), clean(), get_state(), configure().

So the properties of a module object would be.

  • Name
      Simply a way to reference the module.
  • Version
      A number to reference what release this
  • Type
      CVS
        name
          the name in the repository
        location
          :pserver:rslomkow@cvs.gnome.org:/cvs/gnome
        branch
      Release Tar Ball
        name
          basename of tarball
        location
          ftp://ftp.gnome.org/pub/foo/bar/mod-version.tgz
      System Package
        name
          system package name
        location
          ftp://ftp.gnome.org/pub/foo/bar/mod-version.tgz

    • Build Prefixes
        arguments to the configure command
    • Setup Script
        a set of commands to prepare a build area. That are specific to the module.

      At the moment I don't warrent the confusion of additional logic in this object to handle how you build, I am just going to leave that to the configure() and build().

      Now the tricky part is how to allow the user to be able to override parts of the object, in a simple config file. Which brings up the issue, should I create as of yet a new configuration file format? Or should I make it easy for it to be interpreted by my parser. I know all the user interface guys say make it easy for the user! But If I make a new format then they have to learn somthing new! Most people knkow how to write basic perl these days. Also if I make it easily machine interperatable then extending it may be easier.

      Human Interest

      It is amazing how small the software world is. Just a couple years ago, everything was made by mysterious people elsewhere, now I have met the people who wrote most of the software I use. And it seems the web just extends and fills in the gaps. You take a new job and meet another 20.

    • Latest blog entries     Older blog entries

    New Advogato Features

    New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

    Keep up with the latest Advogato features by reading the Advogato status blog.

    If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!