Include file nonsense..
I think I'm going to fix the CVS head: src/Makefile ln -s include freeradius-devel src/main/Makefile src/lib/Makefile src/lib/rules.mak CFLAGS += -I$(top_builddir)/src And then change all of the #include "libradius.h" to #include <freeradius-devel/libradius.h> Which will fix the retarded Solaris issues once and for all. After we clean up the other header files, we can use <freeradius/file.h> for include files everyone should use, and <freeradius-devel/file.h> for include files that exist only in the current build tree. Comments? Alan DeKok.
Would that be better than just adding a hierarchy layer under the src/include directory? So, instead of symlinking freeradius-devel to include during the make process, you just have src/include/freeradius/. Then your include line looks like: #include <freeradius/includefile.h> and your CFLAGS line looks like: CFLAGS += -I$(top_builddir)/src/include I think this would be more along the lines of what other projects do and possibly a little less confusing. --Mike ----------------------------------- Michael Griego Wireless LAN Project Manager The University of Texas at Dallas Alan DeKok wrote:
I think I'm going to fix the CVS head:
src/Makefile ln -s include freeradius-devel
src/main/Makefile src/lib/Makefile src/lib/rules.mak CFLAGS += -I$(top_builddir)/src
And then change all of the
#include "libradius.h"
to
#include <freeradius-devel/libradius.h>
Which will fix the retarded Solaris issues once and for all.
After we clean up the other header files, we can use <freeradius/file.h> for include files everyone should use, and <freeradius-devel/file.h> for include files that exist only in the current build tree.
Comments?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Michael Griego <mgriego@utdallas.edu> wrote:
Would that be better than just adding a hierarchy layer under the src/include directory?
Yeah, except CVS doesn't handle directories very well.
Then your include line looks like: #include <freeradius/includefile.h>
And what happens when we install include files? I want to have *blatant* separation between include files need to build the server, and include files needed to link to libradius. That's why I went with <freeradius-devel/...> as the distinguishing name, rather than <freeradius/...>
and your CFLAGS line looks like: CFLAGS += -I$(top_builddir)/src/include
I think this would be more along the lines of what other projects do and possibly a little less confusing.
Sure, but see my comments about CVS above. I don't think the hack I proposed is too atrocious, and we can always update the directory tree once the #include references have been edited. Alan DeKok.
Alan DeKok wrote:
Michael Griego <mgriego@utdallas.edu> wrote:
Would that be better than just adding a hierarchy layer under the src/include directory?
Yeah, except CVS doesn't handle directories very well.
That's true. If we don't want to lose the history of these files, a workaround consists to copy the files,v inside the repository, and then do a "cvs rm" on the old ones. http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_7.html#SEC73 -- Nicolas Baradakis
Alan DeKok wrote:
I think I'm going to fix the CVS head:
src/Makefile ln -s include freeradius-devel
src/main/Makefile src/lib/Makefile src/lib/rules.mak CFLAGS += -I$(top_builddir)/src
And then change all of the
#include "libradius.h"
to
#include <freeradius-devel/libradius.h>
I'd suggest to always use #include <freeradius/file.h> In src/include/Makefile, we would install the files avalaible for everyone in /usr/include/freeradius, and just ignore the files only needed to build the server. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I'd suggest to always use #include <freeradius/file.h>
I'm just a little paranoid about files that the server needs to build itself, but which aren't needed by anyone using libradius.
In src/include/Makefile, we would install the files avalaible for everyone in /usr/include/freeradius, and just ignore the files only needed to build the server.
Except when you install files from version X, and try to build files with version Y. They get confused. This is exactly the behavior we're seeing on Solaris, where it finds "md5.h", and as a result, doesn't use the one needed to build the server. Sure. I'll take a look at adding versioning information in the header files, which should help address some issues, but won't solve them all. My $0.0.2 is that the server code should use <freeradius-devel/file.h> during build time, and the installed header files should be in /usr/include/freeradius, and include each other as <freeradius/file.h>. This make take some install-time hacks, but I think it's worth it. I've got a Perl script to do the replacement, so it's pretty easy to swap one scheme for another. Alan DeKok.
Alan DeKok wrote:
Except when you install files from version X, and try to build files with version Y. They get confused. This is exactly the behavior we're seeing on Solaris, where it finds "md5.h", and as a result, doesn't use the one needed to build the server.
Yes, that's right.
My $0.0.2 is that the server code should use <freeradius-devel/file.h> during build time, and the installed header files should be in /usr/include/freeradius, and include each other as <freeradius/file.h>. This make take some install-time hacks, but I think it's worth it.
You're suggesting to run sed (or perl) on the header files at install time? That'd prevent any confusion with the FreeRADIUS own build tree, indeed. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
You're suggesting to run sed (or perl) on the header files at install time? That'd prevent any confusion with the FreeRADIUS own build tree, indeed.
Yes. The re-write shouldn't be difficult. I've committed the code and it builds & runs. No more build problems of those kind, at least. Alan DeKok.
participants (3)
-
Alan DeKok -
Michael Griego -
Nicolas Baradakis