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. Go ahead! > Maybe a trunk/kernel/2.6/include/linux/README.symlinks could explain the idea > additionally. OK, patches are welcome. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
