Problem with custom accounting module.

[Bill Schoolfield]

The ability for a software vendor to use an out of the box (OS supplied 
package) FreeRadius server is a big deal. It means we don't have to 
distribute FreeRadius and maintain a bunch of stuff.

Why have modules at all (aside from the shared library benefits) if to 
use custom ones, you have to provide the whole package?

Yes, there are some risks in building the shared library object 
elsewhere (on our build machines, we take the same FreeRadius src as 
that of the OS rpm and build it, then use it on that same host when 
building our shared object files) but it can be done and is being done 
routinely in other applications. So I think the benefits outweigh the risks.

As for the wisdom of changing a structure's "structure" based on a debug 
switch... I've never seen this. Finding the error for me at least took 
an embarrassing long length of time.

I'm not developing FreeRadius so I tread lightly saying this, but I 
think the deployment pattern I described should not necessarily be 
discouraged or prevented.

Bill

On 4/22/2014 8:46 AM, Alan DeKok wrote:
> 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.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
>