[U-Boot-Users] [PATCH] make MAKEALL more immune to merge conflicts

[U-Boot-Users] [PATCH] make MAKEALL more immune to merge conflicts

[Kim Phillips]

..by placing board entries one per line, as suggested by jdl.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
 MAKEALL |  583 +++++++++++++++++++++++++++++++++++++++++++++++----------------
 1 files changed, 436 insertions(+), 147 deletions(-)

diff --git a/MAKEALL b/MAKEALL
index 8c241f6..b69b6bf 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -26,124 +26,281 @@ LIST=""
 ## MPC5xx Systems
 #########################################################################
 
-LIST_5xx="	\
-	cmi_mpc5xx							\
+LIST_5xx="		\
+	cmi_mpc5xx	\
 "
 
 #########################################################################
 ## MPC5xxx Systems
 #########################################################################
 
-LIST_5xxx="	\
-	BC3450		cm1_qp1		cpci5200	EVAL5200	\
-	fo300		icecube_5100	icecube_5200	lite5200b	\
-	mcc200		mecp5200	motionpro	o2dnt		\
-	pf5200		PM520		TB5200		Total5100	\
-	Total5200	Total5200_Rev2	TQM5200		TQM5200_B	\
-	TQM5200S	v38b						\
+LIST_5xxx="		\
+	BC3450		\
+	cm1_qp1		\
+	cpci5200	\
+	EVAL5200	\
+	fo300		\
+	icecube_5100	\
+	icecube_5200	\
+	lite5200b	\
+	mcc200		\
+	mecp5200	\
+	motionpro	\
+	o2dnt		\
+	pf5200		\
+	PM520		\
+	TB5200		\
+	Total5100	\
+	Total5200	\
+	Total5200_Rev2	\
+	TQM5200		\
+	TQM5200_B	\
+	TQM5200S	\
+	v38b		\
 "
 
 #########################################################################
 ## MPC512x Systems
 #########################################################################
 
-LIST_512x="	\
-	ads5121							\
+LIST_512x="		\
+	ads5121		\
 "
 
 #########################################################################
 ## MPC8xx Systems
 #########################################################################
-LIST_8xx="	\
-	Adder87x	GENIETV		MBX860T		R360MPI		\
-	AdderII		GTH		MHPC		RBC823		\
-	ADS860		hermes		MPC86xADS	rmu		\
-	AMX860		IAD210		MPC885ADS	RPXClassic	\
-	c2mon		ICU862_100MHz	MVS1		RPXlite		\
-	CCM		IP860		NETPHONE	RPXlite_DW	\
-	cogent_mpc8xx	IVML24		NETTA		RRvision	\
-	ELPT860		IVML24_128	NETTA2		SM850		\
-	EP88x		IVML24_256	NETTA_ISDN	spc1920		\
-	ESTEEM192E	IVMS8		NETVIA		SPD823TS	\
-	ETX094		IVMS8_128	NETVIA_V2	svm_sc8xx	\
-	FADS823		IVMS8_256	NX823		SXNI855T	\
-	FADS850SAR	KUP4K		pcu_e		TOP860		\
-	FADS860T	KUP4X		QS823		TQM823L		\
-	FLAGADM		LANTEC		QS850		TQM823L_LCD	\
-	FPS850L		lwmon		QS860T		TQM850L		\
-	GEN860T		MBX		quantum		TQM855L		\
-	GEN860T_SC					TQM860L		\
-							TQM885D		\
-							uc100		\
-							v37		\
+LIST_8xx="		\
+	Adder87x	\
+	AdderII		\
+	ADS860		\
+	AMX860		\
+	c2mon		\
+	CCM		\
+	cogent_mpc8xx	\
+	ELPT860		\
+	EP88x		\
+	ESTEEM192E	\
+	ETX094		\
+	FADS823		\
+	FADS850SAR	\
+	FADS860T	\
+	FLAGADM		\
+	FPS850L		\
+	GEN860T		\
+	GEN860T_SC	\
+	GENIETV		\
+	GTH		\
+	hermes		\
+	IAD210		\
+	ICU862_100MHz	\
+	IP860		\
+	IVML24		\
+	IVML24_128	\
+	IVML24_256	\
+	IVMS8		\
+	IVMS8_128	\
+	IVMS8_256	\
+	KUP4K		\
+	KUP4X		\
+	LANTEC		\
+	lwmon		\
+	MBX		\
+	MBX860T		\
+	MHPC		\
+	MPC86xADS	\
+	MPC885ADS	\
+	MVS1		\
+	NETPHONE	\
+	NETTA		\
+	NETTA2		\
+	NETTA_ISDN	\
+	NETVIA		\
+	NETVIA_V2	\
+	NX823		\
+	pcu_e		\
+	QS823		\
+	QS850		\
+	QS860T		\
+	quantum		\
+	R360MPI		\
+	RBC823		\
+	rmu		\
+	RPXClassic	\
+	RPXlite		\
+	RPXlite_DW	\
+	RRvision	\
+	SM850		\
+	spc1920		\
+	SPD823TS	\
+	svm_sc8xx	\
+	SXNI855T	\
+	TOP860		\
+	TQM823L		\
+	TQM823L_LCD	\
+	TQM850L		\
+	TQM855L		\
+	TQM860L		\
+	TQM885D		\
+	uc100		\
+	v37		\
 "
 
 #########################################################################
 ## PPC4xx Systems
 #########################################################################
 
-LIST_4xx="	\
-	acadia		acadia_nand	ADCIOP		alpr		\
-	AP1000		AR405		ASH405		bamboo		\
-	bamboo_nand	bubinga		CANBT		CMS700		\
-	CPCI2DP		CPCI405		CPCI4052	CPCI405AB	\
-	CPCI405DT	CPCI440		CPCIISER4	CRAYL1		\
-	csb272		csb472		DASA_SIM	DP405		\
-	DU405		ebony		ERIC		EXBITGEN	\
-	G2000		HH405		HUB405		JSE		\
-	KAREF		katmai		luan		lwmon5		\
-	METROBOX	MIP405		MIP405T		ML2		\
-	ml300		ocotea		OCRTC		ORSG		\
-	p3p440		PCI405		pcs440ep	PIP405		\
-	PLU405		PMC405		PPChameleonEVB	sbc405		\
-	sc3		sequoia		sequoia_nand	taishan		\
-	VOH405		VOM405		W7OLMC		W7OLMG		\
-	walnut		WUH405		XPEDITE1K	yellowstone	\
-	yosemite	yucca						\
+LIST_4xx="		\
+	acadia		\
+	acadia_nand	\
+	ADCIOP		\
+	alpr		\
+	AP1000		\
+	AR405		\
+	ASH405		\
+	bamboo		\
+	bamboo_nand	\
+	bubinga		\
+	CANBT		\
+	CMS700		\
+	CPCI2DP		\
+	CPCI405		\
+	CPCI4052	\
+	CPCI405AB	\
+	CPCI405DT	\
+	CPCI440		\
+	CPCIISER4	\
+	CRAYL1		\
+	csb272		\
+	csb472		\
+	DASA_SIM	\
+	DP405		\
+	DU405		\
+	ebony		\
+	ERIC		\
+	EXBITGEN	\
+	G2000		\
+	HH405		\
+	HUB405		\
+	JSE		\
+	KAREF		\
+	katmai		\
+	luan		\
+	lwmon5		\
+	METROBOX	\
+	MIP405		\
+	MIP405T		\
+	ML2		\
+	ml300		\
+	ocotea		\
+	OCRTC		\
+	ORSG		\
+	p3p440		\
+	PCI405		\
+	pcs440ep	\
+	PIP405		\
+	PLU405		\
+	PMC405		\
+	PPChameleonEVB	\
+	sbc405		\
+	sc3		\
+	sequoia		\
+	sequoia_nand	\
+	taishan		\
+	VOH405		\
+	VOM405		\
+	W7OLMC		\
+	W7OLMG		\
+	walnut		\
+	WUH405		\
+	XPEDITE1K	\
+	yellowstone	\
+	yosemite	\
+	yucca		\
 "
 
 #########################################################################
 ## MPC8220 Systems
 #########################################################################
 
-LIST_8220="	\
-	Alaska8220	Yukon8220					\
+LIST_8220="		\
+	Alaska8220	\
+	Yukon8220	\
 "
 
 #########################################################################
 ## MPC824x Systems
 #########################################################################
 
-LIST_824x="	\
-	A3000		barco		BMW		CPC45		\
-	CU824		debris		eXalion		HIDDEN_DRAGON	\
-			MOUSSE		MUSENKI		MVBLUE		\
-	OXC		PN62		Sandpoint8240	Sandpoint8245	\
-	sbc8240		SL8245		utx8245				\
+LIST_824x="		\
+	A3000		\
+	barco		\
+	BMW		\
+	CPC45		\
+	CU824		\
+	debris		\
+	eXalion		\
+	HIDDEN_DRAGON	\
+	MOUSSE		\
+	MUSENKI		\
+	MVBLUE		\
+	OXC		\
+	PN62		\
+	Sandpoint8240	\
+	Sandpoint8245	\
+	sbc8240		\
+	SL8245		\
+	utx8245		\
 "
 
 #########################################################################
 ## MPC8260 Systems (includes 8250, 8255 etc.)
 #########################################################################
 
-LIST_8260="	\
-	atc		cogent_mpc8260	CPU86		CPU87		\
-	ep8248		ep8260		ep82xxm		gw8260		\
-	hymod		IPHASE4539	ISPAN		MPC8260ADS	\
-	MPC8266ADS	MPC8272ADS	PM826		PM828		\
-	ppmc8260	Rattler8248	RPXsuper	rsdproto	\
-	sacsng		sbc8260		SCM		TQM8260_AC	\
-	TQM8260_AD	TQM8260_AE	ZPC1900				\
+LIST_8260="		\
+	atc		\
+	cogent_mpc8260	\
+	CPU86		\
+	CPU87		\
+	ep8248		\
+	ep8260		\
+	ep82xxm		\
+	gw8260		\
+	hymod		\
+	IPHASE4539	\
+	ISPAN		\
+	MPC8260ADS	\
+	MPC8266ADS	\
+	MPC8272ADS	\
+	PM826		\
+	PM828		\
+	ppmc8260	\
+	Rattler8248	\
+	RPXsuper	\
+	rsdproto	\
+	sacsng		\
+	sbc8260		\
+	SCM		\
+	TQM8260_AC	\
+	TQM8260_AD	\
+	TQM8260_AE	\
+	ZPC1900		\
 "
 
 #########################################################################
 ## MPC83xx Systems (includes 8349, etc.)
 #########################################################################
 
-LIST_83xx="	\
-	MPC8313ERDB_33	MPC8313ERDB_66	MPC832XEMDS	MPC8349EMDS	\
-	MPC8349ITX	MPC8349ITXGP	MPC8360EMDS	sbc8349		\
-	TQM834x								\
+LIST_83xx="		\
+	MPC8313ERDB_33	\
+	MPC8313ERDB_66	\
+	MPC832XEMDS	\
+	MPC8349EMDS	\
+	MPC8349ITX	\
+	MPC8349ITXGP	\
+	MPC8360EMDS	\
+	sbc8349		\
+	TQM834x		\
 "
 
 
@@ -151,123 +308,223 @@ LIST_83xx="	\
 ## MPC85xx Systems (includes 8540, 8560 etc.)
 #########################################################################
 
-LIST_85xx="	\
-	MPC8540ADS	MPC8540EVAL	MPC8541CDS	MPC8544DS	\
-	MPC8548CDS	MPC8555CDS	MPC8560ADS	MPC8568MDS	\
-	PM854		PM856		sbc8540		sbc8560		\
-	stxgp3		stxssa		TQM8540		TQM8541		\
-	TQM8555		TQM8560						\
+LIST_85xx="		\
+	MPC8540ADS	\
+	MPC8540EVAL	\
+	MPC8541CDS	\
+	MPC8544DS	\
+	MPC8548CDS	\
+	MPC8555CDS	\
+	MPC8560ADS	\
+	MPC8568MDS	\
+	PM854		\
+	PM856		\
+	sbc8540		\
+	sbc8560		\
+	stxgp3		\
+	stxssa		\
+	TQM8540		\
+	TQM8541		\
+	TQM8555		\
+	TQM8560		\
 "
 
 #########################################################################
 ## MPC86xx Systems
 #########################################################################
 
-LIST_86xx="	\
-    MPC8641HPCN	\
+LIST_86xx="		\
+	MPC8641HPCN	\
 "
 
 #########################################################################
 ## 74xx/7xx Systems
 #########################################################################
 
-LIST_74xx="	\
-	DB64360		DB64460		EVB64260	P3G4		\
-	p3m7448		PCIPPC2		PCIPPC6		ZUMA		\
-	mpc7448hpc2
+LIST_74xx="		\
+	DB64360		\
+	DB64460		\
+	EVB64260	\
+	mpc7448hpc2	\
+	P3G4		\
+	p3m7448		\
+	PCIPPC2		\
+	PCIPPC6		\
+	ZUMA		\
 "
 
-LIST_7xx="	\
-	BAB7xx		CPCI750		ELPPC		p3m750		\
-	ppmc7xx								\
+LIST_7xx="		\
+	BAB7xx		\
+	CPCI750		\
+	ELPPC		\
+	p3m750		\
+	ppmc7xx		\
 "
 
-LIST_ppc="${LIST_5xx}  ${LIST_5xxx}		\
-	  ${LIST_8xx}				\
-	  ${LIST_8220} ${LIST_824x} ${LIST_8260} \
-	  ${LIST_83xx}				\
-	  ${LIST_85xx}				\
-	  ${LIST_86xx}				\
-	  ${LIST_4xx}				\
-	  ${LIST_74xx} ${LIST_7xx}"
+LIST_ppc="		\
+	${LIST_5xx}	\
+	${LIST_5xxx}	\
+	${LIST_8xx}	\
+	${LIST_8220}	\
+	${LIST_824x}	\
+	${LIST_8260}	\
+	${LIST_83xx}	\
+	${LIST_85xx}	\
+	${LIST_86xx}	\
+	${LIST_4xx}	\
+	${LIST_74xx}	\
+	${LIST_7xx}	\
+"
 
 #########################################################################
 ## StrongARM Systems
 #########################################################################
 
-LIST_SA="assabet dnp1110 gcplus lart shannon"
+LIST_SA="		\
+	assabet		\
+	dnp1110		\
+	gcplus		\
+	lart		\
+	shannon		\
+"
 
 #########################################################################
 ## ARM7 Systems
 #########################################################################
 
-LIST_ARM7="	\
-	armadillo	B2		ep7312		evb4510		\
-	impa7		integratorap	ap7		ap720t		\
-	lpc2292sodimm	modnet50	SMN42				\
+LIST_ARM7="		\
+	ap7		\
+	ap720t		\
+	armadillo	\
+	B2		\
+	ep7312		\
+	evb4510		\
+	impa7		\
+	integratorap	\
+	lpc2292sodimm	\
+	modnet50	\
+	SMN42		\
 "
 
 #########################################################################
 ## ARM9 Systems
 #########################################################################
 
-LIST_ARM9="	\
-	at91rm9200dk	cmc_pu2						\
-	ap920t		ap922_XA10	ap926ejs	ap946es		\
-	ap966		cp920t		cp922_XA10	cp926ejs	\
-	cp946es		cp966		lpd7a400	mp2usb		\
-	mx1ads		mx1fs2		netstar		omap1510inn	\
-	omap1610h2	omap1610inn	omap730p2	sbc2410x	\
-	scb9328		smdk2400	smdk2410	trab		\
-	VCMA9		versatile	versatileab	versatilepb	\
-	voiceblue							\
+LIST_ARM9="		\
+	at91rm9200dk	\
+	cmc_pu2		\
+	ap920t		\
+	ap922_XA10	\
+	ap926ejs	\
+	ap946es		\
+	ap966		\
+	cp920t		\
+	cp922_XA10	\
+	cp926ejs	\
+	cp946es		\
+	cp966		\
+	lpd7a400	\
+	mp2usb		\
+	mx1ads		\
+	mx1fs2		\
+	netstar		\
+	omap1510inn	\
+	omap1610h2	\
+	omap1610inn	\
+	omap730p2	\
+	sbc2410x	\
+	scb9328		\
+	smdk2400	\
+	smdk2410	\
+	trab		\
+	VCMA9		\
+	versatile	\
+	versatileab	\
+	versatilepb	\
+	voiceblue	\
 "
 
 #########################################################################
 ## ARM10 Systems
 #########################################################################
-LIST_ARM10="	\
-	integratorcp	cp1026						\
+LIST_ARM10="		\
+	integratorcp	\
+	cp1026		\
 "
 
 #########################################################################
 ## ARM11 Systems
 #########################################################################
-LIST_ARM11="	\
-	cp1136		omap2420h4					\
+LIST_ARM11="		\
+	cp1136		\
+	omap2420h4	\
 "
 
 #########################################################################
 ## Xscale Systems
 #########################################################################
 
-LIST_pxa="	\
-	adsvix		cerf250		cradle		csb226		\
-	delta		innokom		lubbock		pleb2		\
-	pxa255_idp	wepep250	xaeniax		xm250		\
-	xsengine	zylonite					\
+LIST_pxa="		\
+	adsvix		\
+	cerf250		\
+	cradle		\
+	csb226		\
+	delta		\
+	innokom		\
+	lubbock		\
+	pleb2		\
+	pxa255_idp	\
+	wepep250	\
+	xaeniax		\
+	xm250		\
+	xsengine	\
+	zylonite	\
 "
 
-LIST_ixp="ixdp425	ixdpg425	pdnb3		scpu"
+LIST_ixp="		\
+	ixdp425		\
+	ixdpg425	\
+	pdnb3		\
+	scpu		\
+"
 
 
-LIST_arm="	\
-	${LIST_SA}							\
-	${LIST_ARM7} ${LIST_ARM9} ${LIST_ARM10} ${LIST_ARM11}		\
-	${LIST_pxa} ${LIST_ixp}						\
+LIST_arm="		\
+	${LIST_SA}	\
+	${LIST_ARM7}	\
+	${LIST_ARM9}	\
+	${LIST_ARM10}	\
+	${LIST_ARM11}	\
+	${LIST_pxa}	\
+	${LIST_ixp}	\
 "
 
 #########################################################################
 ## MIPS Systems		(default = big endian)
 #########################################################################
 
-LIST_mips4kc="incaip"
+LIST_mips4kc="		\
+	incaip		\
+"
 
-LIST_mips5kc="purple"
+LIST_mips5kc="		\
+	purple		\
+"
 
-LIST_au1xx0="dbau1000 dbau1100 dbau1500 dbau1550 dbau1550_el gth2"
+LIST_au1xx0="		\
+	dbau1000	\
+	dbau1100	\
+	dbau1500	\
+	dbau1550	\
+	dbau1550_el	\
+	gth2		\
+"
 
-LIST_mips="${LIST_mips4kc} ${LIST_mips5kc} ${LIST_au1xx0}"
+LIST_mips="		\
+	${LIST_mips4kc}	\
+	${LIST_mips5kc}	\
+	${LIST_au1xx0}	\
+"
 
 #########################################################################
 ## MIPS Systems		(little endian)
@@ -277,36 +534,55 @@ LIST_mips4kc_el=""
 
 LIST_mips5kc_el=""
 
-LIST_au1xx0_el="dbau1550_el"
+LIST_au1xx0_el="	\
+	dbau1550_el	\
+"
 
-LIST_mips_el="${LIST_mips4kc_el} ${LIST_mips5kc_el} ${LIST_au1xx0_el}"
+LIST_mips_el="			\
+	${LIST_mips4kc_el}	\
+	${LIST_mips5kc_el}	\
+	${LIST_au1xx0_el}	\
+"
 
 #########################################################################
 ## i386 Systems
 #########################################################################
 
-LIST_I486="sc520_cdp sc520_spunk sc520_spunk_rel"
+LIST_I486="		\
+	sc520_cdp	\
+	sc520_spunk	\
+	sc520_spunk_rel	\
+"
 
-LIST_x86="${LIST_I486}"
+LIST_x86="		\
+	${LIST_I486}	\
+"
 
 #########################################################################
 ## NIOS Systems
 #########################################################################
 
-LIST_nios="	\
-	ADNPESC1		ADNPESC1_base_32			\
-	ADNPESC1_DNPEVA2_base_32					\
-	DK1C20			DK1C20_standard_32			\
-	DK1S10			DK1S10_standard_32 DK1S10_mtx_ldk_20	\
+LIST_nios="			\
+	ADNPESC1		\
+	ADNPESC1_base_32	\
+	ADNPESC1_DNPEVA2_base_32\
+	DK1C20			\
+	DK1C20_standard_32	\
+	DK1S10			\
+	DK1S10_standard_32	\
+	DK1S10_mtx_ldk_20	\
 "
 
 #########################################################################
 ## Nios-II Systems
 #########################################################################
 
-LIST_nios2="	\
-	EP1C20		EP1S10		EP1S40				\
-	PCI5441		PK1C20						\
+LIST_nios2="		\
+	EP1C20		\
+	EP1S10		\
+	EP1S40		\
+	PCI5441		\
+	PK1C20		\
 "
 
 #########################################################################
@@ -314,31 +590,44 @@ LIST_nios2="	\
 #########################################################################
 
 LIST_microblaze="	\
-	suzaku		ml401		xupv2p
+	suzaku		\
+	ml401		\
+	xupv2p		\
 "
 
 #########################################################################
 ## ColdFire Systems
 #########################################################################
 
-LIST_coldfire="	\
-	cobra5272	EB+MCF-EV123	EB+MCF-EV123_internal		\
-	idmr		M5271EVB	M5272C3		M5282EVB	\
-	TASREG		r5200		M5271EVB			\
+LIST_coldfire="			\
+	cobra5272		\
+	EB+MCF-EV123		\
+	EB+MCF-EV123_internal	\
+	idmr			\
+	M5271EVB		\
+	M5272C3			\
+	M5282EVB		\
+	TASREG			\
+	r5200			\
 "
 
 #########################################################################
 ## AVR32 Systems
 #########################################################################
 
-LIST_avr32="atstk1002"
+LIST_avr32="		\
+	atstk1002	\
+"
 
 #########################################################################
 ## Blackfin Systems
 #########################################################################
 
-LIST_blackfin=" \
-	bf533-ezkit	bf533-stamp	bf537-stamp	bf561-ezkit	\
+LIST_blackfin="		\
+	bf533-ezkit	\
+	bf533-stamp	\
+	bf537-stamp	\
+	bf561-ezkit	\
 "
 
 #-----------------------------------------------------------------------
-- 
1.5.2.2

[U-Boot-Users] [PATCH] make MAKEALL more immune to merge conflicts

[Wolfgang Denk]

Dear Kim,

in message <20070806190637.e284487e.kim.phillips@freescale.com> you wrote:
> ..by placing board entries one per line, as suggested by jdl.


I understand the  intention,  but  at  least  for  me  it  is  pretty
counterproductive.  I  introduced the block formatting some years ago
when the number of boards grew, and the file grew too long.

For example, have a look at the 8xx boards. Here is the old version:

> -LIST_8xx="	\
> -	Adder87x	GENIETV		MBX860T		R360MPI		\
> -	AdderII		GTH		MHPC		RBC823		\
> -	ADS860		hermes		MPC86xADS	rmu		\
> -	AMX860		IAD210		MPC885ADS	RPXClassic	\
> -	c2mon		ICU862_100MHz	MVS1		RPXlite		\
> -	CCM		IP860		NETPHONE	RPXlite_DW	\
> -	cogent_mpc8xx	IVML24		NETTA		RRvision	\
> -	ELPT860		IVML24_128	NETTA2		SM850		\
> -	EP88x		IVML24_256	NETTA_ISDN	spc1920		\
> -	ESTEEM192E	IVMS8		NETVIA		SPD823TS	\
> -	ETX094		IVMS8_128	NETVIA_V2	svm_sc8xx	\
> -	FADS823		IVMS8_256	NX823		SXNI855T	\
> -	FADS850SAR	KUP4K		pcu_e		TOP860		\
> -	FADS860T	KUP4X		QS823		TQM823L		\
> -	FLAGADM		LANTEC		QS850		TQM823L_LCD	\
> -	FPS850L		lwmon		QS860T		TQM850L		\
> -	GEN860T		MBX		quantum		TQM855L		\
> -	GEN860T_SC					TQM860L		\
> -							TQM885D		\
> -							uc100		\
> -							v37		\

This fits easily all on a single screen.

Now your list version is about 4 times as long, and needs more than 2
pages on the (pretty big) window size I'm using. That's much harder to
read.

As for the merge conflict problem: yes,  this  happens  occasionally,
but not very frequently, and this type of merge conflicts are easy to
resolve.


I would like to keep the current formatting.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It seems intuitively obvious to me, which  means  that  it  might  be
wrong.                                                 -- Chris Torek

[U-Boot-Users] [PATCH] make MAKEALL more immune to merge conflicts

[Stefan Roese]

Hi Wolfgang,

On Tuesday 07 August 2007, Wolfgang Denk wrote:
> Now your list version is about 4 times as long, and needs more than 2
> pages on the (pretty big) window size I'm using. That's much harder to
> read.
>
> As for the merge conflict problem: yes,  this  happens  occasionally,
> but not very frequently, and this type of merge conflicts are easy to
> resolve.

I happens to me quite often and I don't see a big advantage in the overview 
view for all the boards on one page.

> I would like to keep the current formatting.

I vote for the new, single-line version suggested by Kim & Jon.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot-Users] [PATCH] make MAKEALL more immune to mergeconflicts

[Martin Krause]

u-boot-users-bounces at lists.sourceforge.net wrote on :
> Hi Wolfgang,
> 
> On Tuesday 07 August 2007, Wolfgang Denk wrote:
> > Now your list version is about 4 times as long, and needs more than
> > 2 pages on the (pretty big) window size I'm using. That's much
> > harder to read. 
> > 
> > As for the merge conflict problem: yes,  this  happens 
> > occasionally, but not very frequently, and this type of merge
> > conflicts are easy to resolve.
> 
> I happens to me quite often and I don't see a big advantage in the
> overview view for all the boards on one page.

Me too.

> > I would like to keep the current formatting.
> 
> I vote for the new, single-line version suggested by Kim & Jon.

Me too!

Best Regards,

Martin Krause
--
TQ-Systems GmbH
Muehlstrasse 2, Gut Delling, D-82229 Seefeld
Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913
Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl
http://www.tq-group.com

[U-Boot-Users] [PATCH] make MAKEALL more immune to mergeconflicts

[David Saada]

I would like to point out another thing that bothers me here: Whenever I take
the most up to date version of U-Boot, I need to perform a merge on MAKEALL,
as my local version includes the names of all my custom boards. I guess I'm
not the only one bothered by this. I suggest that each processor family line
in MAKEALL will hold an additional "external boards" variable, which will
hold a list of all the external boards (for this family). The value of this
variable should be achieved from an "external boards" makefile, included by
MAKEALL. This file is obviously empty in the U-boot repository, and filled
with one's own custom boards elsewhere. 
Just my two cents.
David.


Martin Krause wrote:
> 
> u-boot-users-bounces at lists.sourceforge.net wrote on :
>> Hi Wolfgang,
>> 
>> On Tuesday 07 August 2007, Wolfgang Denk wrote:
>> > Now your list version is about 4 times as long, and needs more than
>> > 2 pages on the (pretty big) window size I'm using. That's much
>> > harder to read. 
>> > 
>> > As for the merge conflict problem: yes,  this  happens 
>> > occasionally, but not very frequently, and this type of merge
>> > conflicts are easy to resolve.
>> 
>> I happens to me quite often and I don't see a big advantage in the
>> overview view for all the boards on one page.
> 
> Me too.
> 
>> > I would like to keep the current formatting.
>> 
>> I vote for the new, single-line version suggested by Kim & Jon.
> 
> Me too!
> 
> Best Regards,
> 
> Martin Krause
> --
> TQ-Systems GmbH
> Muehlstrasse 2, Gut Delling, D-82229 Seefeld
> Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913
> Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH)
> Ruediger Stahl
> http://www.tq-group.com
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 
> 

-- 
View this message in context: http://www.nabble.com/-PATCH--make-MAKEALL-more-immune-to-merge-conflicts-tf4227360.html#a12052243
Sent from the Uboot - Users mailing list archive at Nabble.com.

[U-Boot-Users] [PATCH] make MAKEALL more immune to mergeconflicts

[Wolfgang Denk]

In message <12052243.post@talk.nabble.com> you wrote:
> 
> I would like to point out another thing that bothers me here: Whenever I take
> the most up to date version of U-Boot, I need to perform a merge on MAKEALL,
> as my local version includes the names of all my custom boards. I guess I'm
> not the only one bothered by this. I suggest that each processor family line
> in MAKEALL will hold an additional "external boards" variable, which will
> hold a list of all the external boards (for this family). The value of this
> variable should be achieved from an "external boards" makefile, included by
> MAKEALL. This file is obviously empty in the U-boot repository, and filled
> with one's own custom boards elsewhere. 

What is an "external board"? I don;t understand the concept.

May I instead recommend that you submit your stuff for inclusion in
the public tree?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If I don't document something, it's usually either for a good reason,
or a bad reason.  In this case it's a good reason.  :-)
                 - Larry Wall in <1992Jan17.005405.16806@netlabs.com>

[U-Boot-Users] [PATCH] make MAKEALL more immune to mergeconflicts

[Jon Loeliger]

On Wed, 2007-08-08 at 10:43, Wolfgang Denk wrote:
> In message <12052243.post@talk.nabble.com> you wrote:
> > 
> > I would like to point out another thing that bothers me here: Whenever I take
> > the most up to date version of U-Boot, I need to perform a merge on MAKEALL,
> > as my local version includes the names of all my custom boards. I guess I'm
> > not the only one bothered by this. I suggest that each processor family line
> > in MAKEALL will hold an additional "external boards" variable, which will
> > hold a list of all the external boards (for this family). The value of this
> > variable should be achieved from an "external boards" makefile, included by
> > MAKEALL. This file is obviously empty in the U-boot repository, and filled
> > with one's own custom boards elsewhere. 
> 
> What is an "external board"? I don;t understand the concept.

I think he means more like "extra boards".

> May I instead recommend that you submit your stuff for inclusion in
> the public tree?

Exactly those "extra" boards that have not been sent upstream yet. :-)

jdl

[U-Boot-Users] [PATCH] make MAKEALL more immune to mergeconflicts

[Wolfgang Denk]

In message <1186588768.3283.4.camel@ld0161-tx32> you wrote:
> 
> I think he means more like "extra boards".
> 
> > May I instead recommend that you submit your stuff for inclusion in
> > the public tree?
> 
> Exactly those "extra" boards that have not been sent upstream yet. :-)

Well, in that case we should help David to send these upstream, i. e.
*not* add anything which makes living with "extra boards" easier.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Intuition, however illogical, is recognized as a command prerogative.
	-- Kirk, "Obsession", stardate 3620.7

[U-Boot-Users] [PATCH] make MAKEALL more immune to mergeconflicts

[David Saada]

> I think he means more like "extra boards".
> 
Yes, that was indeed my intention...

> > May I instead recommend that you submit your stuff for inclusion in
> > the public tree?
> 
> Exactly those "extra" boards that have not been sent upstream yet. :-)
I guess I should have been clearer, but John understood my exact take on
this: Our boards will only become operational in about a year. There's no
point in sending them upstream until then (we don't even have
prototypes...).
Furthermore, Wolfgang may disagree here, but I really think that only
reference boards (i.e. boards needed for evaluation of processors etc.)
should be merged into U-boot's main stream repository. Our boards are just
variations of the Freescale reference boards, and I guess that's the same
for many other boards by other companies. I wouldn't want to see ALL these
boards merged into U-boot. Of course that if one finds a problem, or have an
improvement, one's expected to send a patch to the proper place (as I did
with the 83xx Makefile). Needless to say that the boards' code should be
published due to GPL terms, but again - don't think it should be in the main
U-boot repository.
If you agree with me, then my suggestion would spare you the pain of merging
the names of your boards (again - the ones that are either not ready for
upstream merging, or the ones that are not supposed to go to U-boot's repos)
into MAKEALL.
Best regards,
David.

-- 
View this message in context: http://www.nabble.com/-PATCH--make-MAKEALL-more-immune-to-merge-conflicts-tf4227360.html#a12068826
Sent from the Uboot - Users mailing list archive at Nabble.com.

[U-Boot-Users] [PATCH] make MAKEALL more immune to mergeconflicts

[Grant Likely]

On 8/9/07, David Saada <David.Saada@ecitele.com> wrote:
> Furthermore, Wolfgang may disagree here, but I really think that only
> reference boards (i.e. boards needed for evaluation of processors etc.)
> should be merged into U-boot's main stream repository. Our boards are just
> variations of the Freescale reference boards, and I guess that's the same
> for many other boards by other companies. I wouldn't want to see ALL these
> boards merged into U-boot. Of course that if one finds a problem, or have an
> improvement, one's expected to send a patch to the proper place (as I did
> with the 83xx Makefile). Needless to say that the boards' code should be
> published due to GPL terms, but again - don't think it should be in the main
> U-boot repository.

I disagree.  :-)  I think you're opinions makes the assumption that
u-boot is a product.  It is not; it is a process.  What I mean here is
that our primary goal is to continually develop the best bootloader.
The exact set of boards that compiles out of the box is a secondary
objective.  Your argument is that if it's not a generally available
board, then it is uninteresting.  That viewpoint makes sense if you
view u-boot as a thing that you take, modify and ship (ie. a product
which you consume).

However, the u-boot project is about the *process* of developing the
end product.  It involves understanding how u-boot is being used in
real-world scenarios.  It involves recognizing patterns in the code
and consolidating on common patterns.  We *NEED* real world board
ports to have a better understanding of how to improve u-boot.  My
view is exactly the opposite; obscure boards are not uninteresting,
they are extremely interesting.

> If you agree with me, then my suggestion would spare you the pain of merging
> the names of your boards (again - the ones that are either not ready for
> upstream merging, or the ones that are not supposed to go to U-boot's repos)
> into MAKEALL.
> Best regards,
> David.
>
> --
> View this message in context: http://www.nabble.com/-PATCH--make-MAKEALL-more-immune-to-merge-conflicts-tf4227360.html#a12068826
> Sent from the Uboot - Users mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] [PATCH] make MAKEALL more immune to mergeconflicts

[Wolfgang Denk]

Dear David,

in message <12068826.post@talk.nabble.com> you wrote:
> 
> Furthermore, Wolfgang may disagree here, but I really think that only
> reference boards (i.e. boards needed for evaluation of processors etc.)
> should be merged into U-boot's main stream repository. Our boards are just
> variations of the Freescale reference boards, and I guess that's the same
> for many other boards by other companies. I wouldn't want to see ALL these
> boards merged into U-boot. Of course that if one finds a problem, or have an

Grant already replied on this, and I just want to point  out  that  I
absolutely  agree  with him. Just taking a huge amount of code that's
publicly available for free, adding your own little stuff  and  never
returning  it  to  the  community  is something what happens here and
there, but it is definitely NOT the way the free  software  community
works, and in my opinion also pretty unethical.

Even if your board is just a minor variation of some reference  board
it  is  nevertheless  important  to  have  your changes and additions
merged back into the public U-Boot source code. Guess how support for
all that many types of flash chips, RTCs, PHYs, network  controllers,
...  you  nameit ... got into the U-Boot tree? Not because these were
used on reference boards, but on the  plethora  of  different  custom
boards we support.

Guess where allt eh fancy features are  coming  from  -  support  for
graphical  console,  splash screen, net console, VLAN, POST code, ...
came from? None of this was done for  any  reference  board,  it  was
all done for custom boards.


U-Boot would never even be half of what it is today if we added  only
reference boards.



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Real Programmers always confuse Christmas and Halloween because
OCT 31 == DEC 25 !  - Andrew Rutherford (andrewr at ucs.adelaide.edu.au)

[U-Boot-Users] [PATCH] make MAKEALL more immune to mergeconflicts

[Timur Tabi]

On Aug 8, 2007, at 11:43 AM, Wolfgang Denk wrote:

> What is an "external board"? I don;t understand the concept.

I think David is suggesting that we divide MAKEALL into multiple  
files, one per processor family or something like that.  For  
instance, all Freescale boards could have their own MAKEALL file, so  
that if someone creates a new ARM board, there is no way there would  
be a merge conflict.

Either way, I am also voting for the one-board-per-line change.  I  
hate merge conflicts, even easy ones, so I'm in favor of any change  
that reduces them.

[U-Boot-Users] [PATCH] make MAKEALL more immune to merge conflicts

[Detlev Zundel]

Hi,

> I happens to me quite often and I don't see a big advantage in the overview 
> view for all the boards on one page.
>
>> I would like to keep the current formatting.
>
> I vote for the new, single-line version suggested by Kim & Jon.

I *think* my precursors already got Wolfgang to change the format, but
just for the records - I would also like to switch to a single line
version.

Cheers
  Detlev

-- 
Obversely, a lot of verbal mileage can also be gotten by sending out in-
comprehensible, cryptic, confusing or unintelligible messages, and then
iteratively "correcting" the "mistaken interpretations" in the replys.
           -- Proposed Symbolics guidelines for mail messages (1984)
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot-Users] [PATCH] make MAKEALL more immune to merge conflicts

[Wolfgang Denk]

In message <m2sl6u0y37.fsf@ohwell.denx.de> you wrote:
> 
> I *think* my precursors already got Wolfgang to change the format, but
> just for the records - I would also like to switch to a single line
> version.

D*mn. Seems I'm on the side of snake eyes tossed against the side  of
seven again :-(


But then we should do things Right (tm):

Then please get rid of the same lists in the README as well.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I have made mistakes, but have never made the mistake of  claiming  I
never made one.                                     - James G. Bennet

[U-Boot-Users] [PATCH] make MAKEALL more immune to merge conflicts

[Kim Phillips]

On Wed, 08 Aug 2007 20:09:21 +0200
Wolfgang Denk <wd@denx.de> wrote:

> 
> But then we should do things Right (tm):
> 
> Then please get rid of the same lists in the README as well.

you mean delete the outdated CPU Type, Board Type, and NAME_config
lists?

Kim

[U-Boot-Users] [PATCH] make MAKEALL more immune to merge conflicts

[Wolfgang Denk]

In message <20070810025436.0d294d8d.kim.phillips@freescale.com> you wrote:
> 
> > Then please get rid of the same lists in the README as well.
> 
> you mean delete the outdated CPU Type, Board Type, and NAME_config
> lists?

Yepp...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Q:  How many IBM CPU's does it take to execute a job?
A:  Four; three to hold it down, and one to rip its head off.

[U-Boot-Users] [PATCH] make MAKEALL more immune to merge conflicts

[Kim Phillips]

On Tue, 07 Aug 2007 08:48:48 +0200
Wolfgang Denk <wd@denx.de> wrote:

> > -	FPS850L		lwmon		QS860T		TQM850L		\
> > -	GEN860T		MBX		quantum		TQM855L		\
> > -	GEN860T_SC					TQM860L		\
> > -							TQM885D		\
> > -							uc100		\
> > -							v37		\
> This fits easily all on a single screen.

I can't imagine the level of pain one would have to (unnecessarily)
endure resolving a conflict in the 8xx list (the columns don't even
have equal lengths).

> Now your list version is about 4 times as long, and needs more than 2
> pages on the (pretty big) window size I'm using. That's much harder to
> read.

true, but at least it's sorted alpha now.

> As for the merge conflict problem: yes,  this  happens  occasionally,
> but not very frequently, and this type of merge conflicts are easy to
> resolve.

I'd rather say adieu to them period, given the number of trees one has
to merge to get what u-boot code they want these days.

> I would like to keep the current formatting.
> 

I think you're placing too much emphasis over your /static/
aesthetics over the aesthetics of /change/, e.g. here's a patch I'm
about to send you (assuming you apply this patch):