Hello all, On Thursday 01 of October 2015 23:59:05 Peter Dufault wrote: > Chris, Makefile isn’t custom support, it’s legacy support. For better or > for worse, if you add barriers to Makefiles you raise eyebrows in the > legacy community. They can understand an effort to adapt from BSD make to > GNU make, but a lack of Makefile support is a check-box not checked. I > don’t know of any other build systems that have the footprint of “make”. > > Yes, the twisty auto* mess is a mess, but it does promise Makefile support.
In the fact, I think there is no replacement generic enough for autoconf. But it can be used without automake, for example GIT uses this setup. As for RTEMS, I do not mind if automake and autoconf are eliminated. I have stuck on simple atempt to copy of rtems/testsuites/libtests/tar02 to rtems/testsuites/samples/tar02 now. I hoped to speedup that way preparation of testcase for untar 4.11 regression (build RTEMS only with --enable-tests=samples). But for some reasons bootstrap/automake does not understand my intention. And generally, I do not like automake too much. On the other hand, there are many clean (GNU) make based large projects - Linux kernel etc. In that regard, I like much Linux kernel configuration system which allows to configure complex combinations of options with interdependencies. More projects use standalone version of these tools with their (usually make based) build systems http://ymorin.is-a-geek.org/projects/kconfig-frontends Important is that whole selected configuration is stored in human readable form and can be versionned. But CMAKE combined with Ninja seems to work well for ReactOS and there exist much more well working options. As for RTEMS BSP parameters, my preference is if they are stored in clean, human and tools readable form after installation. The current make compatible format (i.e. lines KEY=VALUE) looks to me as sane. I have some fear if that information is installed in form of some algorithm/tool even common to more BSPs that I cannot be confident with long term guaranteed exact match to the values used during BSP build. There is not so much required. I.e. values for CC or CC_FOR_TARGET, etc. (AS, AR, LD ..), CFLAGS, CPPFLAGS, LDFLAGS and LIBS. The most other is in bsp_specs and linkcmds. Or is it expected to remove these as well? Where is expected be stored this infomation in the new build system after BSP install? Best wishes, Pavel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
