Next article in the “Writing Free Software” series

Hey all,

I’m not certain what the next topic should be. I’ve got a few ideas. Could the interested parties let me know what they’re curious most about?

  • documentation
  • distributing .exe.config and .dll.config files
  • inter-package dependencies using pkg-config
  • creating sub packages
  • test harnesses and the “check” target
  • the debian/ directory and .deb packages
  • … something completely different

I’m looking for comments on this one!

This entry was posted in autotools, c#, CLI, debian, Free Software, mono, pkg-config, Software, test. Bookmark the permalink.

16 Responses to Next article in the “Writing Free Software” series

  1. popi says:

    Maybe Debian packages ( We know the most used linux desktop distribution is Debian Based)….

    And one time we had a package Alien may do the rest…

  2. Tobias says:

    I’d love to hear about how the “check” target works, could you describe that for us, please? :)

  3. pkg-config, then .deb packages for me.

  4. Alexander says:

    I really like your “Writing Free Software” series. It helps me to understand such things as distribution packages for a [project] based on Mono. But I [personally] prefer FreeBSD, others may prefer something else, so I don’t think things like debian specific details must [be] at the top of your list. As for me it would be great if this things would be next:
    » distributing .exe.config and .dll.config files
    » inter-package dependencies using pkg-config
    » creating sub packages

  5. Jason Schluter says:

    pkg-config

  6. Nathan Samson says:

    My intrests are (in order), but note that I’m already used more or less to autopackage

    * documentation
    * the debian/ directory and .deb packages
    * test harnesses and the “check” target
    * creating sub packages
    * distributing .exe.config and .dll.config files

  7. Johannes says:

    I’ve been missing the NAnt way of building projects. As I’m not sure if Autotools (and its software stack like configure, make, …) are available under Windows, I question the ROI to tutor people in Autotools. As you chose C#, using a platform dependent way seems to contradict the promise of the CLR. Granted, people manage to write platform dependent (N)Ant scripts while not even using system commands, but that’s where education comes in.

  8. Cover the Application Deployment Guidelines:

    http://www.mono-project.com/Guidelines:Application_Deployment

    With a segue to pkg-config and -pkg:package-name, which is used for unstable packages (see http://www.mono-project.com/Guidelines:Application_Deployment#Libraries_with_Unstable_APIs)

    I would be remiss if I didn’t suggest covering monodoc either. No library is complete without documentation on every public type and member.

  9. @Johannes: Autotools runs on Windows, though it does require a few extra things to be installed. So, at least they’re portable. :-) ./configure scripts do tend to run a lot slower, though, because they take advantage of the host system’s ability to spawn extra processes, and process creation is a very expensive process on Windows.

    It’s not *terribly* different from being a developer on any other operating system, though, since you (for the most part) have to install things like the autotools system components on any system (they do not often come “out of the box”). The only major difference is that you need something like Cygwin (or natively built-versions that use MSYS and MINGW).

  10. Hey there Johannes,

    I can cover NAnt. I’ll probably do it by way of Prebuild though, since I don’t know much about the system.

    Yes, Autotools works on windows. Both with cygwin and mingw. mingw doesn’t work on amd64 operating systems, though. Woe. I think it’s just because it hasn’t been built on that platform.

    Thanks for the comment!

    C.J.

  11. Thanks for the more in-depth response to the windows-based autotools question, Michael. You put it much better than me :)

  12. Thanks jonp. Yes, I’ve been thinking I’d make the next one documentation.

    I think it’s going to take at least two more articles to get to the -pkg:foo bits. One to separate NDesk.Options into its own package with a .pc.in file, and one to add PKG_CHECK_MODULES to the application package.

    The application deployment guidelines will probably be quite a few articles :) Good stuff there.

  13. Thanks Nathan. One more point for documentation as the next article :)

  14. Thanks Jason. I think pkg-config is important, too. As I mentioned in my response to jonp, I think that will be at least two articles. I’ll schedule it after one (or two) on writing docs.

  15. —–BEGIN PGP SIGNED MESSAGE—–
    Hash: SHA1

    Alexander,

    It’s good to hear that this article helps FreeBSD users. I’m not very familiar with the platform, but from what I’ve seen, I’m impressed. Please pardon my editing of your article. No offense is intended.

    Do you know whether dpkg will run on FreeBSD? If so, I bet the whole apt stack will work there. I know a lot of FreeBSD folks who like the ports setup on that platform. I don’t know much about it myself, but it seems like a good way to get close to the distribution process. I’ve found that with a little work and some coaching from Debian Developers like Mirco Bauer and Seo Sanghyeon go a long way toward exposing the process of fetching, building and patching the source of the Debian packages. I’d like to see the process available to those on non-linux distributions. In case you’re looking for a project. Ha.
    —–BEGIN PGP SIGNATURE—–
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFIqCkQXKBS0hdr6UYRAkFNAJ4sJIbqyu+GQFtRyw/iknkWySyTIwCePhGm
    s+UznBkpPmnZAwEZFLdUT10=
    =BjR+
    —–END PGP SIGNATURE—–

  16. David Perfors says:

    I would be at least very interested in package dependencies and subpackages. Basicly because you never use only a program that is this small. It is probably a good thing to combine it with unit testing.
    Debian packaging would be useful as well

Leave a Reply