Problem with custom accounting module.

Alan DeKok aland at deployingradius.com
Tue Apr 22 15:46:04 CEST 2014


Arran Cudbard-Bell wrote:
> I'm deferring to Alan D because IIRC he had strong objections to including NDEBUG in features.h last time this came up.

  The issue is that NDEBUG is used to turn debugging on / off for many
projects.  I won't want to screw up someone else's project with
definitions specific to FR.

  I don't see what's so hard about building your module with the same
definitions used by FR.  If you're building production systems, define
NDEBUG.  If you're developing, don't define NDEBUG.

  And do this consistently.  The problem seems to be people who build
modules using their own development tree, and then expect to use them
with pre-built packages.  This is *entirely* wrong.

  If you're going to build modules for (say) redhat, you will need to
add your module to the "tar" file, use the RH spec files, update it for
your module, and re-build the *entire* redhat  package.  Then,
distribute only the RPM for your module.

  Doing anything else is a recipe for disaster.  When the package
maintainer sets some random build flag, your "custom built" module will
stop working.  And you'll blame me.

  If you're using packages, use packages.  For EVERYTHING.  Otherwise,
you'll need to build a custom version of the server, and distribute
that.  You then have complete control over the build.

  But expecting to do "git checkout;make; ..." and have it build a
module compatible with a random vendor re-package of FreeRADIUS is just
wrong.  That might work by magic, but there's no guarantee it will ever
work correctly.

  Alan DeKok.


More information about the Freeradius-Devel mailing list