From: "Lewis" Received: from [192.168.100.201] (account lgrosenthal@2rosenthals.com HELO [192.168.100.23]) by 2rosenthals.com (CommuniGate Pro SMTP 5.4.10) with ESMTPSA id 912020 for cwmm-dev@2rosenthals.com; Wed, 22 Jul 2020 12:13:17 -0400 Subject: Re: [cwmm-dev] Proposed sync merge of TW localization into v2.9 branch To: CWMM Developers Mailing List References: Message-ID: <5F18659C.8090207@2rosenthals.com> Date: Wed, 22 Jul 2020 12:13:16 -0400 User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit HI... On 07/22/20 01:37 am, Steven Levine wrote: > In , on 07/22/20 > at 01:06 AM, "Lewis" said: > > Hi Lewis, > >> Speaking of which... Are there enough loose makefiles floating around the >> repo? Egad. It seems that every language has a makefile for something >> which could have been done with a single file a level or two above which >> was not NLV-specific. Oh, well. It's a process. > This is exactly how the xwp repo does NLVs. It's a style I prefer. A > project that insists on doing everything from a single top-level makefile > is probably a project I'm not terribly interested in working on. > > When I need to make a small change to some file in some subdirectory, I > prefer to be able to drop into the directory and type make and be done > with it. I don't care to be forced to wait for a top-level make file to > figure out that 99% of the code does not need to be rebuilt. Recall that I did not say *one* top-level makefile. I simply find it inefficient to have: /classes/res/makefile and then: /classes/res/xx/makefile So it goes. I also thought I spied several dupes along the way, but I may have been reading too fast. I wouldn't suggest that a single makefile at the top would be preferable at all. >> Steve, any comment before I dive into this? > I'm not too picky on how things are named, although I agree that > > classes/res/nl/audioconv_nl.dlg > > could shortened to audioconv.dlg with not loss of information. > > When laying this kind of stuff out my focus tends to be to try to make > sure the layout will still make sense after I've been away from the > project for 6 months or so. > > I also try to not reinvent the wheel. No layout is perfect and the > existing layout worked for Chris. Apparently so. -- Lewis