Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming Ximian IT Technology

Novell Releases Ximian's Build Buddy 29

Posted by timothy from the do-it-all dept.
BB maintainer Dan Mills writes "The Ximian Build System, Build Buddy, is now available to the community. This is a very exciting moment, and one that many of us at Ximian have been hoping would come. Build Buddy is a cross-platform packaging system designed with flexibility, reproducibility, and automation in mind. It features: support for producing RPM, Deb, and SD (HP-UX) packages; a testing/package verification framework; Red Carpet integration; command-line and Web interfaces; support for remote build scheduling via XML-RPC; reproducible build environments (chroot jails); and flexible XML package metadata description. Sound interesting? Visit primates.ximian.com/~thunder/bb for other documentation and links. We are very interested in starting a user and developer community around BB. Feel free to contact us via the mailing lists if you have any questions."
This discussion has been archived. No new comments can be posted.

Novell Releases Ximian's Build Buddy More

Novell Releases Ximian's Build Buddy

Comments Filter:

  • shop and compare (Score:4, Interesting)

    by 4of12 ( 97621 ) on Wednesday January 28, 2004 @06:38PM (#8117988) Homepage Journal

    I'd be curious to know how buildbuddy compares to other tools like autoconf, automake, and gentoo's portage system.

    • One way to find out:
      emerge buildbudy --pretend

    • Re:shop and compare (Score:2, Informative)

      by v_thunder ( 194192 )
      BB is not an autotools replacement. Its primary purpose is packaging.

      A typical setup to build something with BB will use autotools, or MakeMaker, or whatever the module requires to prepare, build, and install.

      As for the portage system, I have not looked at it much, but I think that it should not be hard to add support to BB for gentoo's binary packages.

      HTH,
      -Dan
  • I'm not downloading till they have .debs of it...

  • Are you serious? (Score:4, Interesting)

    by Cecil ( 37810 ) on Wednesday January 28, 2004 @06:41PM (#8118036) Homepage
    A build system with the objective of being less arcane than autoconf? HOORAY!

    Seriously though, build systems is one place where, despite all its bugs and shortcomings, Microsoft Visual Studio kicks the shit out of autoconf/jam/whatever else. It's not cross platform nor very configurable, admittedly, but as far as ease of use goes it is in an entirely different universe from standard UNIX build systems.

    Hopefully Build Buddy can strike a decent balance between ease of use and configurability. I'm looking forward to checking it out.

    • Re:Are you serious? (Score:4, Informative)

      by saden1 ( 581102 ) on Wednesday January 28, 2004 @07:20PM (#8118523)
      Huh? Are you talking about compiling or building a distribution package?

      You have to use MSI build tool to package your application for windows platform now (safest and best method according to MS) and VS has a crappy packaging tool. And if you have ever used one of the commercial MSI build tools you know it is not easy. I must say though that Wise Installer is one of the best out there but its flexibility leaves much to be desired. Still, it is better than InstallShield but still pain in the ass if you want to do complex stuff.
      • Both, I suppose.

        Visual Studio admittedly does not do the packaging part itself, but MSDN (which is basically yet another expensive required component of VS) includes an MSI builder, if I am not mistaken. They aren't ridiculously easy, say, compared to Wise. But they are still a whole lot easier than autoconf/automake.

        What other posters have said is true, though. Most of the difficulty in autotools is related to the crossplatform nature. Although really, I think a few well placed default configurations cou

    • Re:Are you serious? (Score:3, Insightful)

      by be-fan ( 61476 )
      You've obviously never used SCONS.
    • Well, if you remove the requirement of being cross-platform or being very configurable, it isn't all that hard to create a simple build system anymore, now is it? Most of the mess that is in the (horrible, I agree) auto* tools is due to those two requirements.

      • All I have to say is even with Windows you have dll hell! What works on win98 don't always work on win2k. Windows system is indeed a nightmare when it comes to getting your application to work on all flavors of it.
      • True. I glossed over that aspect, and that's my fault. However, the blatant nastiness that is autotools could really be significantly improved by simply adding and maintaining some groups of common, default setups. The whole thing is kludged together with macros, so it isn't like it'd be technically difficult. I'd offer to do it, if I could figure out how the damn tools work.

        Even still, it's not a very well thought-through system. If it was really targetted at cross platform builds, there is no reason why
        • And again, I fully agree with you - they are horrible, kludgy, ad-hoc and messy. And as you say, they persist in changing important parts of the functionality in incompatible ways between versions - right now I have four different versions of automake installed (1.4 to 1.7) because the devels can evidently not be bothered to actually keep compatibility between minor versions.

          That said, having a build system to handle all Unix-like OS:es _will_ be complex and messy - not nearly as complex and messy as the s

    • Re:Are you serious? (Score:3, Informative)

      by Haeleth ( 414428 )
      Microsoft Visual Studio kicks the shit out of autoconf

      Apples and oranges. The whole PURPOSE of autoconf is to compile code on multiple disparate platforms. If you're only writing for one platform, you'd be an idiot to use autoconf. And if you're using Visual Studio, you're only writing for one platform - by definition.
      • And if you're using Visual Studio, you're only writing for one platform - by definition.

        not really - you can customize the build process in visual studio to use a different compiler (like gcc) if you wanted to.
    • That's a little bogus. If all I wanted to do was change the set of C files to compile and change the libraries to link with and did not worry about cross platform, I could do that easily by editing a Makefile. In fact it is far easier to add/remove a C file from a Makefile than from VC++.

      Now admittedly creating the Makefile to get to the point where you can match VC++ is really a pain in the ass and the result is incredibly ugly. But that is like saying VC++ is a pain because you have to write it from scra
    • Comment removed based on user account deletion
    • I think BB's biggest strength is precisely its cross-platform abilities.

      This project was born when at Ximian we realized that we were duplicating a lot of work when creating similar packages for multiple distributions. Many times, even information across packaging systems (e.g., between rpm and deb equivalents of the same module) is shared.

      So at heart, BB is an attempt to unify to some extent these different packaging systems, across multiple platforms. BB is the reason Ximian was able to ship Ximian De

  • But... (Score:2, Funny)

    by Mikkeles ( 698461 )
    "It features: support for producing RPM, Deb, and SD (HP-UX) packages; a testing/package verification framework; Red Carpet integration; command-line and Web interfaces; support for remote build scheduling via XML-RPC; reproducible build environments (chroot jails); and flexible XML package metadata description."

    But can it read mail? [wlug.org.nz]

Slashdot Top Deals

If you have a procedure with 10 parameters, you probably missed some.

Close