Re: [kbuild-devel] Re: Handling boolean subsets of objects
[Peter] > >You can also have a list of CONFIGs, can you not? In which case you > >have a parsing problem either way. [kaos] > select() takes exactly one CONFIG_, select_cond() takes exactly two. > No kbuild 2.5 command takes a variable sized list of CONFIGs. OK, if you say multiple dependent CONFIG_ variables are not needed, I'm happy to take your word for it. > >I still don't see why the code can't just do as dep_tristate does: "if > >there exists an 'n', return 'n', else if there exists an 'm', return > >'m', else return 'y'". > CONFIG_ISDN CONFIG_ISDN_PPP slhc.o > n - n > y n n > y y y > m n n > m y m Uh, I guess we're talking in circles, but AFAICT we are describing the same truth table. The only difference is that your version may be easier to do in a makefile, because you assume the second variable must be a bool. *If* we can assume that a 'n' variable will not be '' instead [yes, I know, we can't assume that at present], the makefile implementation is trivial: ifeq(,$(findstring n,$(CONFIG_FOO)$(CONFIG_BAR)) ifneq(,$(findstring m,$(CONFIG_FOO)$(CONFIG_BAR))) # compile as module else # compile builtin endif endif > The first config has priority, the second only selects a subset. If you can come up with an example where doing it your way with the variables in the correct order (like your table above) produces a different result than my algorithm with the variables in *either* order, I promise to slap myself for being stupid, and then shut up. Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Handling boolean subsets of objects
On Sun, 28 Oct 2001 20:39:42 -0600, Peter Samuelson <[EMAIL PROTECTED]> wrote: > > [peter] >> >select_cond(CONFIG_ISDN slhc.o CONFIG_ISDN_PPP) > >[kaos] >> That is worse, you can select a list of objects, where does the >> second config go? > >You can also have a list of CONFIGs, can you not? In which case you >have a parsing problem either way. select() takes exactly one CONFIG_, select_cond() takes exactly two. No kbuild 2.5 command takes a variable sized list of CONFIGs. >I still don't see why the code can't just do as dep_tristate does: "if >there exists an 'n', return 'n', else if there exists an 'm', return >'m', else return 'y'". # only included if CONFIG_ISDN != n bool ' Support synchronous PPP' CONFIG_ISDN_PPP CONFIG_ISDN controls if the overall isdn code is built and how it is built. CONFIG_ISDN_PPP selects slhc.o using a boolean statement but the result is really tristate. CONFIG_ISDN CONFIG_ISDN_PPP slhc.o n - n y n n y y y m n n m y m The first config has priority, the second only selects a subset. The dep_tristate rules do not work for this case, we have quite a few in the kernel. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Handling boolean subsets of objects
[peter] > >select_cond(CONFIG_ISDN slhc.o CONFIG_ISDN_PPP) [kaos] > That is worse, you can select a list of objects, where does the > second config go? You can also have a list of CONFIGs, can you not? In which case you have a parsing problem either way. Distinguishing between a CONFIG option and an object file may not make for a pretty parser, but it is not difficult. Any hacker who names a file CONFIG_FOO.c deserves what he gets. > >Come to think of it, does it really matter what order the CONFIG > >options come in? Isn't this more or less just like dep_tristate, which > >does a boolean AND of the existing options anyway (say m==1, y==3)? > > No, the first config is the main one, the second config selects a > subset of the main code. I still don't see why the code can't just do as dep_tristate does: "if there exists an 'n', return 'n', else if there exists an 'm', return 'm', else return 'y'". Is there a functional reason not to do this, or is it merely a matter of awkwardness in the generated makefile? Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Handling boolean subsets of objects
On Sun, 28 Oct 2001 20:11:21 -0600, Peter Samuelson <[EMAIL PROTECTED]> wrote: >[kaos] >> select_cond(CONFIG_ISDN CONFIG_ISDN_PPP slhc.o) >> >> Both configs must be selected, either as 'y' or 'm'. The first config >> defined how the object is compiled. I am worried that this might be >> confusing, some users are bound to get the config options in the wrong >> order. Any ideas for a less ambiguous construct? > >select_cond(CONFIG_ISDN slhc.o CONFIG_ISDN_PPP) That is worse, you can select a list of objects, where does the second config go? >Come to think of it, does it really matter what order the CONFIG >options come in? Isn't this more or less just like dep_tristate, which >does a boolean AND of the existing options anyway (say m==1, y==3)? No, the first config is the main one, the second config selects a subset of the main code. CONFIG_FOO=m CONFIG_BAR=y select_cond(CONFIG_FOO CONFIG_BAR object list) is different from select_cond(CONFIG_BAR CONFIG_FOO object list). The first builds the object list as modules, the second as built in. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Handling boolean subsets of objects
[kaos] > select_cond(CONFIG_ISDN CONFIG_ISDN_PPP slhc.o) > > Both configs must be selected, either as 'y' or 'm'. The first config > defined how the object is compiled. I am worried that this might be > confusing, some users are bound to get the config options in the wrong > order. Any ideas for a less ambiguous construct? select_cond(CONFIG_ISDN slhc.o CONFIG_ISDN_PPP) In fact, you *could* overload select() for this, as long as you can differentiate between CONFIG options and targets. Come to think of it, does it really matter what order the CONFIG options come in? Isn't this more or less just like dep_tristate, which does a boolean AND of the existing options anyway (say m==1, y==3)? Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Handling boolean subsets of objects
Several Makefile.in files have code like this ifsel(CONFIG_ISDN_PPP) select(CONFIG_ISDN slhc.o) endif The select() defines how the object is compiled, the ifsel is a boolean that decides if the object is built at all. I am thinking about adding a new construct: select_cond(CONFIG_ISDN CONFIG_ISDN_PPP slhc.o) Both configs must be selected, either as 'y' or 'm'. The first config defined how the object is compiled. I am worried that this might be confusing, some users are bound to get the config options in the wrong order. Any ideas for a less ambiguous construct? ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Add update_if_changed()
Some generated files have a lot of dependencies and a lot of dependents. For this case it is worth doing a micro optimization to detect if the generated contents have changed since the last time. The obvious example is asm-offsets.h. Most asm-offsets.h have large dependency trees, arch/i386/asm-offsets.s depends on 160 .h files plus their config options (our include tree is spaghetti), yet a change to most of those files has no effect on the generated asm-offsets.h. IA64 is even worse, with a larger dependency list for asm-offsets.s and more files affected by a change to asm-offsets.h. This patch against kbuild 2.5-2.4.13-1 adds update_if_changed(). Take a look at it before I release it to the world. Index: 13.11/Documentation/kbuild/kbuild-2.5.txt --- 13.11/Documentation/kbuild/kbuild-2.5.txt Sun, 28 Oct 2001 21:02:09 +1100 kaos (linux-2.4/G/e/50_kbuild-2.5 1.32 644) +++ 13.12(w)/Documentation/kbuild/kbuild-2.5.txt Mon, 29 Oct 2001 01:47:41 +1100 kaos +(linux-2.4/G/e/50_kbuild-2.5 1.33 644) @@ -564,6 +564,25 @@ MAKEFILE.IN SYNTAX base_target(vmlinux) is semi-reserved, it can be specified in a makefile but it always refers to the top level vmlinux. +update_if_changed(target new_target) +If the new_target is newer than target and they are not identical +then replace the contents of target with the contents of new_target. +This command is normally used for text files generated by +user_command(), the new_target is generated but only replaces target +if anything has changed. The new_target parameter can be omitted, it +defaults to the target name prefixed with 'tmp_' (not '.tmp_'). + +Obviously there must be another command that generates new_target. +Do not use a new_target name that starts with '.', dot files are +special cases in kbuild and will not do what you expect. The target +is automatically marked as nodepend(), the only thing it depends on +is the new_target, there is no need for other dependency data. + +update_if_changed() is a micro optimization, resist the temptation to +use it in too many places. Only use it when a significant number of +files are affected by a change to the target, so the saving in +reduced compilation is worth the less readable code in the makefile. + hostcc(object_list) Compile the objects to run on the host system. It uses HOSTCC, the standard include list, HOSTCFLAGS plus any extra flags for the @@ -1549,10 +1568,11 @@ CONTROLLING KBUILD TEMPORARY FILES FOR KBUILD - All the temporary files and directories create by kbuild start with - '.tmp_'. Only the kbuild team needs to know what is in these files, but a - brief list might be useful to the general build audience. This list is - roughly in the order they appear in the top level and scripts Makefiles. + All the temporary files and directories created by kbuild start with + '.tmp_' or 'tmp_'. Only the kbuild team needs to know what is in these + files, but a brief list might be useful to the general build audience. + This list is roughly in the order they appear in the top level and scripts + Makefiles. .tmp_include_list A shell script which, when executed, returns the external include list, @@ -1674,6 +1694,11 @@ TEMPORARY FILES FOR KBUILD fed back into the lexical analyser for macro expansion. It uses this temporary file for the feedback, the feedback is never more than one level. + + tmp_ +Used with update_if_changed() to decide if a file has changed or not. +The default for the second parameter of update_if_changed() is the target +prefixed with 'tmp_'. ADDITIONAL TARGETS AND COMMANDS Index: 13.11/Makefile-2.5 --- 13.11/Makefile-2.5 Mon, 08 Oct 2001 16:39:45 +1000 kaos (linux-2.4/E/d/40_Makefile-2 1.32 644) +++ 13.12(w)/Makefile-2.5 Mon, 29 Oct 2001 01:30:33 +1100 kaos +(linux-2.4/E/d/40_Makefile-2 1.32 644) @@ -346,6 +346,7 @@ clean: $(KBUILD_OBJTREE).tmp_global_make -o -name '.SUMS' \ -o -name '.tmp_implicit' \ -o -name '.tmp_*_shipped' \ + -o -name 'tmp_*' \ -o -size 0 \ \) -type f -print | xargs -r rm -f $(KBUILD_QUIET)cd $(KBUILD_OBJTREE) && rm -rf $(CLEAN) Index: 13.11/arch/i386/Makefile.in --- 13.11/arch/i386/Makefile.in Sat, 06 Oct 2001 15:24:26 +1000 kaos (linux-2.4/E/d/43_Makefile.i 1.13 644) +++ 13.12(w)/arch/i386/Makefile.in Mon, 29 Oct 2001 01:33:41 +1100 kaos +(linux-2.4/E/d/43_Makefile.i 1.13 644) @@ -12,7 +12,7 @@ extra_aflags(vmlinux.lds.i -no-tradition # into # symbol = value /* 0xvalue source */ -user_command(asm-offsets.h +user_command(tmp_asm-offsets.h ($(objfile asm-offsets.s)) (set -e; (echo "#ifndef __ASM_OFFSETS_H__"; @@ -41,3 +41,5 @@ us
[kbuild-devel] Announce: Kernel Build for 2.5, Release 1.4 updated to 2.4.13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii Release 1.4 of kernel build for kernel 2.5 (kbuild 2.5) has been updated to kernel 2.4.13. http://sourceforge.net/projects/kbuild/, Package kbuild-2.5, download release 1.4. http://marc.theaimsgroup.com/?l=linux-kernel&m=99725412902968&w=2 contains information about the base release. No changes to the main kbuild code, just a bunch of Makefile.in changes to track 2.4.13, plus some spelling corrections. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE72/Tti4UHNye0ZOoRAm3rAJwLVY6SSCnVzVMILkiegQ3PR9H6JQCcCpuU d2FG7Yrp9DV3FL/BBAebOO0= =KVBd -END PGP SIGNATURE- ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
