On Mon, May 16, 2022 at 09:30:22AM -0700, Richard Cochran wrote: > On Mon, May 16, 2022 at 06:19:01PM +0300, Vladimir Oltean wrote: > > > What I usually do when I need to determine whether a feature is > > available is to compile a dummy C program using the same CFLAGS as the > > main program itself. > > Well you probably love autoconf then. > > I don't. > > What I have for linuxptp is based on decades of my own very > frustrating experience in embedded. > > I am not going to change the build system, especially not compiling > test programs to find things out. That method is simply hacky. > > Sorry, > Richard
No, I didn't say I love autoconf or that you should use autoconf. I just pointed out that incdefs.sh doesn't work unless you point it to the kernel headers, because it insists on grepping through files rather than just working with the provided C environment, which is what you _actually_ want. I also compile the Linux kernel so I won't set KBUILD_OUTPUT unless I want to garble my toolchain sysroot with junk. The main problem is that incdefs.sh guesses incorrectly where the header files are, if I don't point KBUILD_OUTPUT to them. It can stop doing that, and guess better, if you can just reimplement incdefs.sh using some other approach, not migrate to the full-blown autotools. I'd rather have something hacky that works and plays nice with other people's environments rather than something hacky that doesn't. But ok, maybe I'm doing something wrong. How do you set up a cross compilation environment that works for linuxptp and for the kernel? _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
