Oliver Hartkopp wrote: > Wolfgang Grandegger wrote: >> Oliver Hartkopp wrote: >>> Wolfgang Grandegger wrote: >>>> Oliver Hartkopp wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Oliver Hartkopp wrote: >>>>>>>>> AFAIK you can only create symlinks for real files (not directories) >>>>>>>>> in the >>>>>>>>> SVN. I would suggest to replace the .h-files in 2.6/include/linux with >>>>>>>>> symlinks pointing to the .h-files in 2.6/include/socketcan >>>>>>>> But we could do it in the Makefile, as the Linux kernel does for >>>>>>>> include/asm. >>>>>>> Hm - i still don't have a idea how this is done. >>>>>>> >>>>>>> For me it would be important, that userspace Makefiles like the current >>>>>>> can-utils/Makefile do not need to be changed. >>>>>>> >>>>>>> Is this possible? >>>>>> No. >>>>> Too bad. >>>>> >>>>> I know from several simple userspace build environments (or when you even >>>>> have >>>>> no environment/Makefile) that they rely on defining an additional include >>>>> path >>>>> to compile. >>>>> >>>>> Creating symlinks inside these Makefiles (if available) would touch a huge >>>>> number of userspace Makefiles to be modified. >>>> OK, I agree. >>>> >>>>> Can we make it the other way round that the Makefiles in kernel/2.6 can be >>>>> changed to create a symlink as you suggested? >>>> To avoid the symbolic links, what about replacing the header files as >>>> show below: >>>> >>>> $ cd trunk/kernel/2.6/include/linux >>>> $ cat can.h >>>> #include <socketcan/can.h> >>>> $ cat can/error.h >>>> #include <socketcan/can/error.h> >>> IMHO this only hides the symlink by creating an unvisible 'include-link' >>> >>> For me a symlink makes it more clearly what is going on there. >> I personally find symbolic links more confusing, because you don't know >> what file you really edit/modify. Well, but that's a matter of taste. > > Argh! > > I remember, why we had two separate paths containing nearly the same stuff:
We separated them to avoid conflicts with the *almost* similar kernel include files and that works well. You can disable CAN support in the kernel config and build all modules from BerliOS without any trouble. As a consequence, we can develop and test now new interfaces (touching the header files) without kernel interference. > All of these include file are including other includes files in the same > include paths. So a symlink nor your #include approach will help us here :-( My approach did work fine with the can-utils. > Maybe it's just a matter of 'developing process' that the patches for the > SocketCAN repository use 'include/socketcan' ... and the changes in the > include/socketcan need to be applied (by us) to include/linux (if needed). "include/linux" is only need for the CAN utils, as you told us. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
