directory prefix in freeradius-devel vs. include

Eran Pasternak eran.pasternak at forescout.com
Thu Oct 22 10:55:38 CEST 2015


Good to know! Thank you for straightening things up for me.

Eran


-----Original Message-----
From: Freeradius-Devel [mailto:freeradius-devel-bounces+eran.pasternak=forescout.com at lists.freeradius.org] On Behalf Of Alan DeKok
Sent: Wednesday, October 21, 2015 7:29 PM
To: FreeRadius developers mailing list
Subject: Re: directory prefix in freeradius-devel vs. include

On Oct 21, 2015, at 9:56 AM, Eran Pasternak <eran.pasternak at forescout.com> wrote:
> First let me clarify that I use one machine for development (where I compile radius ) and another for testing (where I run radius). The problem was that on the testing machine, radclient tried to access the dictionary in a path different from the one defined in Make.inc (and src/include/radpath.h). Now, thanx to your reply, I understand the reason. In my development env, 'freeradius-devel' was not a softlink but an actual directory! Seems that in one of the earliest code-branching the actual content of the link was copied and since this directory is not *configured*, radpath.h in it wasn't updated - and of course this is the file used for compilation.

  That would explain it.

> So now I just have a question to better understand the usage of all these directories - please correct me if I'm wrong:
> /src/include - contains the source headers for development.

  The source headers for the version you are currently building.

> /src/freeradius-devel - is a softlink to this dir, which facilitates experimenting with APIs (or any header definitions) by allowing to create copies of the include dir. without altering all the c files.

  No.  It has nothing to do with altering C files.  It's all about include file paths.

 We never install anything to /usr/include/freeradius-devel.  So we can *guarantee*  that there is no standard include path of /usr/include/freeradius-devel/.

 Which means that when the source code does:

#include <freeradius-devel/foo.h>

   We can *guarantee* that the source code finds the header files from the build tree, and not any installed header files.

  If instead the source did:

#include <freeradius/foo.h>

  We would have *no idea* whether the compiler picks /usr/include/freeradius/foo.h, or src/include/foo.h.  And those files can be different.

> /usr/include - the installed copy of the headers. This allows using their content for developing or changing modules on the machine itself.

  Pretty much, yes.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
WARNING - CONFIDENTIAL INFORMATION:
________________________________
The information contained in the e-mail may contain confidential and privileged information and is intended solely for the use of the intended recipient(s). Access for any review, re-transmission, dissemination or other use of, or taking of any action in regard and reliance upon this e-mail by persons or entities other than the intended recipient(s) is unauthorized and prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments.



More information about the Freeradius-Devel mailing list