I am not a deep makefile specialist, but the last project we worked on, had lines similar to what I wrote, and the process was just started once for all files on the line.
in our case I would say: dMake genLang And that should cause dmake to start "genLang -m<module name> -t<target dir> src1.hrc src2.xcd ...." I will just check with my former colleagues, maybe they did something more. I will write your list of variable names on my drawboard and try to keep it. Have a nice evening. Jan. On 6 November 2012 19:33, Andre Fischer <awf....@gmail.com> wrote: > On 11/6/12 5:59 PM, jan iversen wrote: > >> @andre: >> >> I just saw one line in your mail, that I forgot to respond to....you look >> for the interesting part of the code, the file tree scanner. >> >> There are no tree scanning with the new concept, it is done by the >> makefile. >> >> Each makefile (or build.lst) is extended with something like: >> >> genLang: src1.hrc src2.xcd .... >> genLang -m<module name> -t<target dir> $* >> >> Thereby each single developer decides which files get scanned, and build >> get rid of this big tree scanning. >> > > So collecting the files to process is done by the makefile and passed via > $* ? Sounds reasonable. > > But calling genLang for all files in one directory introduces a number of > sub processes, although not as much as before. And much better than before. > > > >> Sorry that I forgot to mention that in my first mail. >> >> Jan. >> >> >> On 6 November 2012 16:12, jan >> iversen<jancasacondor@gmail.**com<jancasacon...@gmail.com>> >> wrote: >> >> HI >>> >>> Thanks for your input, it is not too harsh, I prefer straight comments >>> than something I have to read several times to understand. >>> >>> I will not disturb your session, but I have put some reasons/answers >>> below. >>> >>> rgds >>> Jan I. >>> >>> On 6 November 2012 14:38, Andre Fischer<awf....@gmail.com> wrote: >>> >>> On 11/4/12 1:55 PM, jan iversen wrote: >>>> >>>> Hi. >>>>> >>>>> I have finished the control part of the new localization tool, and >>>>> before I walk further down the line (writing/converting all the >>>>> translations parts) I would like to have checked if the code is ok in >>>>> terms >>>>> of standard, readability and expectations (from other C++ programmers). >>>>> >>>>> I hope one of the C++ programmers, can have a quick look at the code >>>>> and >>>>> tell me: >>>>> - Are the code written in accordance with the AOO standards (I think >>>>> so) >>>>> - Is it in general in accordance with the AOO writing style. >>>>> >>>>> - C++ files usually have file extensions of .cxx and .hxx >>>> >>>> - There are some conventions of naming variables like mnSomthing for a >>>> numerical member variable. >>>> >>>> I can live with you using a different naming scheme but would ask to >>>> change the file extensions. >>>> >>> >>> I will change the extensions, no problem...I use hungarian notation for >>> variables, and I know that some system require e.g. int variable to start >>> with a lower case "i", something I am not to much friend of, because it >>> gets very cluttered when you make your own classes. >>> >> > We don't use full hungarian notation, just an m for member variables and > then and n for numbers, s for strings, r for references, p for pointers, a > for everything else. But I am a big friend of formatting your code as you > feel comfortable with. But try to keep it readable by others. Eventually > your code will have to be maintained by somebody else. > > > >>> >>> >>>> >>>> Of course, I would very much like to hear if there are non-efficient / >>>>> malicious code in there, but please remember this is only the control >>>>> skeleton, so there are a lot of code missing. >>>>> >>>>> I only found one thing: >>>> >>>> genConvert.cpp convert_gen::getConverter >>>> >>>> - There are two if statements at the start of the method. The second >>>> looks like it should be a "else if" instead. >>>> >>>> UPS, corrected. >>> >>> - The return at the bottom looks unreachable. >>>> >>>> The return is actually just to please the compiler, it cannot be >>> reached...but try to remove the statement and you get errors. >>> >> > Ah, I see. > > > >>> >>> >>>> >>>> But the main thing that I am not sure about is whether C++ is the right >>>> language for this. I am not sure because I have not found the >>>> interesting >>>> part of the program: how the file tree is traversed, how external tools >>>> are >>>> called, or whether there are not external tools anymore. >>>> >>>> If the main task of genLang is to traverse the file tree and call >>>> external tools, then a script language like Perl might be better suited >>>> and >>>> would speed up implementation a lot. >>>> >>> >>> No, there will be no external tools...all will be embedded in genLang, I >>> am right now embedding transex3 (which is a lex grammar), each conversion >>> is done as its own class, making it easy to expand. >>> >>> Localize_sl, spawns today different processes, written in C++, Lex, bash, >>> python and bash....that is not maintainable, making it with classes as >>> one >>> program in C++ makes it easier to maintain. >>> >> I agree and I am glad that you are doing it this way. I also agree that > C++ is the right choice of language when all the external tools are > integrated. > > > >>> I have done some speed test (based on some input I got on localize_sl). >>> On >>> windows localize_sl takes about 2 minutes to complete "sw" directory, >>> mainly due to spawning a new process for each file. My preliminary test >>> makes me believe that genLang will do the same in less than 10 seconds. >>> >>> >>> >>>> >>>> I try to include a zip file with this mail, should I not succeed, then >>>>> please respond to the mail and I will sent it directly. >>>>> >>>>> If the above sounds too harsh, then that is because I am currently >>>> sitting in the BoF seesion and am trying to concentrate on two things at >>>> the same time. >>>> >>>> THANKS for taking time, have a nice session. >>> >>> I have on the other hand been searching for unit test tools, it seems we >>> are not really using that....my biggest fear is to build something (of >>> course with high reuse of source) without being able to guarantee that >>> the >>> output is identical to the old process. >>> >> > Yes, using unit tests would be good. Don't be as lazy as the rest of us > :-) > > > >>> >>> -Andre >>>> >>>> >>>> >>>> MANY Thanks in advance for the help. >>>>> Jan. >>>>> >>>>> >>>>> >
