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: 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 :-( 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). Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
