MonitorWare Knowledge Base

Peter Vrabec has introduced me to the idea of moving rsyslog's build system to GNU autotools and has also provided a first patch actually doing the change. That patch, however, is not yet part of 1.15.0. I am currently thinking how to go forward in the best possible way. This thread shall aid decision finding.

For starters, here are some links to the autotools:

http://vindaci.members.sonic.net/cbreak ... oconf.php3
http://www-src.lip6.fr/homepages/Alexan ... otools.pdf

Comments appreciated.
Rainer

• Custom written rsyslog.conf?
• Maintenance Contract?
• Installation support?

And one more link, I needed to fiddle around the link limit spam protection

http://www.niksula.hut.fi/~mkomu/docs/autohowto.html

And the book on the topic (completely available online):

http://sourceware.org/autobook/autobook ... k_toc.html

I am a bit concerned of moving immediately to autotools (even though I would like to do so), because it can possible break the package build process for soma packagers. On the other hand, I'd like to start as soon as possible using them, there seems to be much value in it.

What kind of problems do you expect? Autotools are widely used in many projects across many distributions. I wouldn't expect it's a big deal for maintainers to package rsyslog(with autotools) and adjust it to the build process.

What do you think about releasing 1.15.0 and 1.16.0(with autotools) at the same time? Man can choose if he wants release with "old" makefile or new autotools stuff.

1.15.0 is already out. I think I can not use the "old" makefile together with autotools (becaue Makefile would be overwritten). I am concerned that I break automatted procedure - but probably I am too concerned here

I think that mixing old system in rsyslog with autotools is possible, but that would be very ugly.

What automated procedure do you mean? From maintainres angle of view, creating a package is not automated since there are people doing this job.

Looks like I am thinking a bit o complicated. I remember that some folks told me they pull new versions automatically and previous changes in the make system broke their procedures. Anyhow, I have just realized that we indeed could "just" add the new autoconf and let the old makefile remain for a while. That would not be a real mix-up and be removed in 1.16.0. I would like to use the new 1.16.x number to flag a some more serious change. On the other hand, I have some fixes right now for the new 1.15.x functionality which I would like to release as 1.15.x. Anyhow, it's all a matter of a few days. But I have to admit I am very excited about the possibilities of autotools.

Rainer

OK, I've made my mind up. As nobody screamed when I asked about autotools, it'll probably a painless move. Anyhow, I'll finish 1.15.1 today with a few bug fixes and release that one (without autotools). The very next thing to happen will be the integration of autotool, culminating in 1.16.0, probably out tomorrow or so That 1.16.x version will then receive all the good things.

I have just released 1.15.1, which concludes the 1.15.x release series. I will now apply Peter's patch to rsyslog and see that it works with autotools. That includes review of conditional compilation switches etc.

Just for the records: I have added Peter's patch, but also fiddled a little myself with the files. Initially, I broke a lot, but I finally got it to work again

The current code is now in anonymous CVS. And that version was successfully pulled and compiled on at least one other machine (yes, I had to re-try multiple times). So it looks like we got started. I have not yet pulled the old build system, but intend to do so. I would appreciate any comments on the current CVS state.

I've noticed this morning that I had forgotten to include config.h in some sources. resulting in very strange problems (structure alignment and such). This is now done, the CVS is updated.

Bartosz Kuźma also offered in-depth help moving to autotools. I'll work through his list.

As of this writing, the SYSV macro has been removed from rsyslogd code.

Now, the SYSLOG_INET macro is a --enable-inet definition for configure. Code in CVS.