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.