Does anyone use the nant build besides me (I use it to make the Windows binaries)?

I'm just using the VS2005 solutions, but wouldn't it mean that instead of 1 prebuild, the solution, nant and autotools files have to be maintained?

Yes. It is a tradeoff. I will maintain the VS2005 and nant build. I will create the autotools files and will let Sam Hocevar of Debian maintain them.

I've been trying NAnt on linux today, but it seems it doesn't quite like FFmpegPlayer's Resources.resx. Complains about not being able to find the bitmap, which in turn blocks the whole build.

Thanks. I fixed it. I had to remove the resource in svn. This was a bug in prebuild's NAnt target. It looks like I'll be removing the VS2005 and nant prebuild stuff, but will have to leave it for autotools at the moment since it is much more complex.

I have removed the prebuild portions of the NAnt and vs2005 builds. Prebuild is still used for autotools. Let me know if there are any problems.

Since I've been playing around with NAnt a bit for the snapshot build, I've rather started to like it. Now I've been thinking that it'd be nice if we could replace the autotools with NAnt for distro packaging. There are several advantages. It's easier to maintain, we finally get completely rid of prebuild and it's peculiarities. It's less error-prone and we can edit the NAnt files directly, which imho are a lot more readable than makefiles. Also NAnt 0.86 is going to support VS2005 solutions, so in the future we can reduce maintenance even further. The disadvantage is that NAnt would be required int the build environment.

I've already added an experimental 'install' target to my local NAnt build files. It seems that to create a RPM for my SUSE install it's as easy as adding NAnt to BuildRequires and replacing 'make' 'make install' with 'nant mono-2.0 build-release' and 'nant mono-2.0 install', but I'm still working on that. I've no idea however how Debian does things and if something like it would be possible or if distros actually prefer the makefiles as they are right now.

Actually, I have started to investigate what targets would be necessary to use NAnt in debian. I noticed that the Nunit package in debian uses NAnt and not autotools. It would be very nice to use NAnt for the Linux distro builds.

I now managed to build the SUSE rpms using NAnt . I'll commit the NAnt scripts to SVN, so we can try to get it working on Debian too.

These are the build commands that I used in the .spec file:
BuildRequires: nant mono-core pkg-config mono-devel
....
%prep
%setup

%build
nant mono-2.0 build-release

%install
nant mono-2.0 install -D:gacdir="$RPM_BUILD_ROOT%{_prefix}" -D:pkgconfig="$RPM_BUILD_ROOT%{_prefix}/lib/pkgconfig"

%clean
rm -rf "$RPM_BUILD_ROOT"

The result can be found on the SUSE build service.

Is it possible to check in the spec files as well? Maybe under a suse directory in the Tao root? It may be useful for building files for other rpm type distros

yow. It seems I'm a little late to this party, but I object

The reason we put it in was so that there would be an equally up-to-date build system for all supported build platforms.

If files get added to the process and the autotools maintainer is offline for a year (that never happens! ), what do the folks who depend on the autotools build system do?

I'll go read the rest of the thread now...

yeah, vs2k* auto-includes the resource's namespace. autotools, nant and monodevelop do not. The prebuild targets for each could be fixed, but we don't use prebuild any longer

Is it possible to check in the spec files as well? Maybe under a suse directory in the Tao root? It may be useful for building files for other rpm type distros

Dave, I would use svn references rather than putting the spec files directly in the repository. duplication of data is bad, and will get us out-of-date if a maintainer forgets to sync on a regular basis.

This assumes that Novell keeps the spec files in svn...

$ svn help ps
propset (pset, ps): Set the value of a property on files, dirs, or revisions.
usage: 1. propset PROPNAME PROPVAL PATH...
2. propset PROPNAME --revprop -r REV PROPVAL [TARGET]

1. Creates a versioned, local propchange in working copy.
2. Creates an unversioned, remote propchange on repos revision.
TARGET only determines which repository to access.
...
svn:externals - A newline separated list of module specifiers,
each of which consists of a relative directory path, optional
revision flags, and an URL. For example
foo http://example.com/repos/zig
foo/bar -r 1234 http://example.com/repos/zag
...

I'll try to keep a branch with the prebuild.xml. I'll fiddle with the prebuild source so that it generates something useable. Sam has convinced me that prebuild is not yet mature enough to support this project. I'll do what I can to make it work, but I don't want you all to block on me

Looks like you got the wrong idea about the spec file. It's just my try at rewriting the official SUSE spec from autotool to NAnt, so it's nowhere else to be found. Being in SVN, it provides an example for distro packagers of how we figured to do the packaging (see SVN). I agree that the if we'd like to have the files needed for packaging, we should use externals.

Okay, the autotools build should be almost complete now. Thanks for being patient, it's something I promised back in December...

What I'm missing is a way to create .config files at configure time by looking for libraries available on the system. But distributing .config.in files instead of .config files would probably break all other build systems, so I'm certainly not doing it. Can anyone think of a way to do it without interfering too much with the other build systems?