Jump to content

SnakeByte

EstablishedMember
  • Content Count

    46
  • Joined

  • Last visited

Everything posted by SnakeByte

  1. Using BoostC 2.2.5 Beta, if I try to compile the following code, I get the errors I would expect to get when something isn't properly defined: #include <system.h> #define TEST randomstring void main() { int someValue = TEST; } defineTest.c(7:18): error: unknown identifier 'randomstring' defineTest.c(7:16): error: failed to initialize variable 'someValue' ... Same goes with normal template usage.. I get the same appropriate error: #include <system.h> #define INT_VALUE randomstring template <class T> T GetMax (T a, T b) { return (a>b)? a : b; } void main () { int i=2, j; j=GetMax<int>(INT_VALUE,i); } defineTest.c(13:16): error: unknown identifier 'randomstring' defineTest.c(13:16): error: unknown template identifier 'GetMax' ... but when I attempt to layout my code like how the current lcd_driver.h does it, the unknown identifier error vanishes and I'm left with the generic "failed to generate expression": #include <system.h> #define INT_VALUES 1, randomstring #define getmax GetMax<INT_VALUES> template <int a, int b> int GetMax( void ) { return (a>b)? a : b; } void main () { int j; j=getmax(); } defineTest.c(15:4): error: failed to generate expression defineTest.c(15:4): error: invalid operand 'GetMax<1, randomstring>()' defineTest.c(15:3): error: failed to generate expression Now, the second error should help me determine what's going on, but depending on the code that's written, that 2nd error doesn't always occur and I'm only left with the "failed to generate expression" errors. Depending on the amount of nesting being done with the #defines, this can make troubleshooting a big pain in the ... Just as a FYI, I found that if attempt to compile this code with gcc, that I am given the error, so this might be worth trying if anyone else is having trouble identifying why that error is happening. gcc test.cpp -I ./include/ -D_PIC16F876 -D_BOOSTC test.cpp:15: `randomstring' undeclared (first use this function) test.cpp:15: template argument 2 is invalid test.cpp:15: no matching function for call to `GetMax()' Thanks!
  2. Just downloaded version 2.2.5 of sourceboost... Noticed a change in the PicDem2plusDemo.c file: #ifndef _PIC16F877 #warning "This code is configured for PIC16F877 or PIC18F452. If you use other targets you may need to reconfigure the project." #endif
  3. Of course it won't compile if you just change the target. The code is configured to use TRISD/PORTD registers and 16F876 doesn't have them. You need to reconfigure the project to use different ports to make it compile for 16F876. Regards, Pavel <{POST_SNAPBACK}> Duh! Thanks Pavel... For some reason I thought it was only using ports A and B... I see that in the code it does show that it's using D... I guess that got changed back when I was having trouble with the v1.10 version of lcd_driver.h #define LCD_ARGS 1, /* Interface type: mode 0 = 8bit, 1 = 4bit(low nibble), 2 = 4bit(upper nibble) */ \ 1, /* Use busy signal: 1 = use busy, 0 = use time delays */ \ PORTD, TRISD, /* Data port and data port tris register */ \ PORTA, TRISA, /* Control port and control port tris register */ \ 3, /* Bit number of control port is connected to RS */ \ 2, /* Bit number of control port is connected to RW */ \ 1 /* Bit number of control port is connected to Enable */ Is there any way to ask the compiler to tell when defines like PORTD and TRISD aren't defined? That would have made this simple to figure out.
  4. Dave, If you still have that project I e-mailed you, attempt to change the target from a 16F877 to a 16F876. While everything compiles fine with the 877, once I change the target in mplab I get this output: Clean: Deleting intermediary and output files. Clean: Deleted file "Picdem2PlusDemo.OBJ". Clean: Deleted file "C:\\microchip\demo2board\demo2board.HEX". Clean: Done. Executing: "C:\Program Files\SourceBoost\boostc.pic16.exe" Picdem2PlusDemo.c -O1 -W1 -v -t 16F876 BoostC Optimizing C Compiler Version 2.2.2 Beta (for PIC16 architecture) http://www.picant.com/c2c/c.html Copyright© 2004-2005 Pavel Baranov Copyright© 2004-2005 David Hobday Picdem2PlusDemo.c success Picdem2PlusDemo.c(93:2): error: failed to generate expression Picdem2PlusDemo.c(102:2): error: failed to generate expression Picdem2PlusDemo.c(103:2): error: failed to generate expression Picdem2PlusDemo.c(114:2): error: failed to generate expression Picdem2PlusDemo.c(115:2): error: failed to generate expression Picdem2PlusDemo.c(116:2): error: failed to generate expression Picdem2PlusDemo.c(127:2): error: failed to generate expression Picdem2PlusDemo.c(132:2): error: failed to generate expression Picdem2PlusDemo.c(133:2): error: failed to generate expression Picdem2PlusDemo.c(134:2): error: failed to generate expression Picdem2PlusDemo.c(143:2): error: failed to generate expression Picdem2PlusDemo.c(148:2): error: failed to generate expression Picdem2PlusDemo.c(149:2): error: failed to generate expression Picdem2PlusDemo.c(150:2): error: failed to generate expression Picdem2PlusDemo.c(159:2): error: failed to generate expression Picdem2PlusDemo.c(164:2): error: failed to generate expression Picdem2PlusDemo.c(165:2): error: failed to generate expression Picdem2PlusDemo.c(166:2): error: failed to generate expression Picdem2PlusDemo.c(175:2): error: failed to generate expression Picdem2PlusDemo.c(180:2): error: failed to generate expression Picdem2PlusDemo.c(181:2): error: failed to generate expression Picdem2PlusDemo.c(182:2): error: failed to generate expression Picdem2PlusDemo.c(191:2): error: failed to generate expression Picdem2PlusDemo.c(210:2): error: failed to generate expression Picdem2PlusDemo.c(277:2): error: failed to generate expression Picdem2PlusDemo.c(291:2): error: failed to generate expression Picdem2PlusDemo.c(291:2): error: Error in the body of 'while' expression Picdem2PlusDemo.c(299:2): error: failed to generate expression Picdem2PlusDemo.c(300:2): error: failed to generate expression Picdem2PlusDemo.c(302:2): error: failed to generate expression Picdem2PlusDemo.c(303:2): error: failed to generate expression Picdem2PlusDemo.c(304:2): error: failed to generate expression Picdem2PlusDemo.c(305:2): error: failed to generate expression Picdem2PlusDemo.c(319:2): error: failed to generate expression Picdem2PlusDemo.c(320:2): error: failed to generate expression Picdem2PlusDemo.c(321:2): error: failed to generate expression Picdem2PlusDemo.c(350:2): error: failed to generate expression Picdem2PlusDemo.c(351:2): error: failed to generate expression Picdem2PlusDemo.c(353:2): error: failed to generate expression Picdem2PlusDemo.c(397:2): error: failed to generate expression Picdem2PlusDemo.c(398:2): error: failed to generate expression Picdem2PlusDemo.c(403:2): error: failed to generate expression Picdem2PlusDemo.c(404:2): error: failed to generate expression Picdem2PlusDemo.c(416:2): error: failed to generate expression Picdem2PlusDemo.c(417:2): error: failed to generate expression Picdem2PlusDemo.c(460:2): error: failed to generate expression Picdem2PlusDemo.c(536:2): error: failed to generate expression Picdem2PlusDemo.c(537:2): error: failed to generate expression Picdem2PlusDemo.c(553:2): error: failed to generate expression Picdem2PlusDemo.c(554:2): error: failed to generate expression Picdem2PlusDemo.c(574:2): error: failed to generate expression Picdem2PlusDemo.c(579:2): error: failed to generate expression Picdem2PlusDemo.c(580:2): error: failed to generate expression Picdem2PlusDemo.c(588:2): error: failed to generate expression Picdem2PlusDemo.c(589:2): error: failed to generate expression failure BUILD FAILED: Tue Apr 26 23:18:22 2005
  5. Dave, I got the "bad" header from this thread: http://sourceboost.ipbhost.com/index.php?showtopic=956 You provide a temporary link to the file at post #6: http://www.hob68.f2s.com/lcd/lcd13-03-05.zip When I originally checked the two files to see which was newer, all I saw was the date 15'th of november 2004 from the installation version without any versions while the header file located in that zip file showed the 1.10 revision... I see now that you moved the revision information from its' original location down a page and that the version that comes with the installer is version 1.11. D'oh! Now that this is all finally figured out, I just have one more question... the 16F876 should be functionally equal to the 16f877 except for the extra two ports D and E right? Is the 876 not able to drive an lcd display or is the lcd_driver stuff still a work in progress?
  6. Dave, One of the things I forgot to do after re-installing sourceboost was to use your v1.10 version of the lcd_driver.h file... Surprisingly things compiled fine... It's only when I use that newer version that things break as reported before. It looks like the problem with my original post was because I wasn't using the 16F877 as my target (I had the 16F876 set instead), and the problem with my 3rd post was due to that newer header file.
  7. Yes, specify -v in the compiler extra command line options. If you zip up the project and send it to me I'll take a quick look (support@picant.com) Regards Dave <{POST_SNAPBACK}> Dave, I Figured it out. I uninstalled SourceBoost 5.9.5, manually removed the directory, re-installed sourceboost, installed the 2.2.3 update, and everything compiled fine afterwards. I kept a copy of the original sourceboost dir before doing all of this, and will do a file compare to see what's going on... Perhaps the sourceboost 5.9.5 installer isn't overwriting all of the files and is leaving some stale files behind.
  8. The finds the default include folder by looking at the path to boostc.exe and adding "\include" to that path. Enviroment variables are not used. Regards Dave <{POST_SNAPBACK}> Dave, When I posted the original message, I was using the original, but then after reading that other thread, I gave your 1.10 a try. While it still doesn't compile, the error messages are a bit more vebose: picdem2plusDemo.c(93,59): error: no template identifier 'LCD_Setup' matches the number of arguments in the call picdem2plusDemo.c(93,2): error: failed to generate expression What's odd is that LCD_Setup doesn't have any arguments both as declared in your header file, and when called from the source file. I get these errors for each of the lcd functions that are being called. Is there any way to increase verbosity further, or run the compiler enough for it to output the source file after macro/template substitution but before actual compilation?
  9. Ah, looks like this is related to the lcd_driver.h file problems.
  10. I've followed the instructions detailed in C:\Program Files\SourceBoost\boostc.html as far as boostc integration with mplab and am attempting to compile the sample code picdem2plusdemo.c file but am still having difficulties. When I try to build the source, I'm getting a ton of "error: failed to generate expression" errors, and I'm guessing this is because the compiler doesn't know where to find the needed include files. Even after adding the include and library paths to the "Default search paths and Directories" for the project, and making sure that the lib and the source file is added to the project, those errors remain. What step am I missing? Does the compiler use environment variables to find the include and lib dirs? Will the compiler complain if it cannot find a header or source file?
  11. I've written another perl script.. this time it will take the .inc files and convert them to header files, much like the inc2h app. I've made two additional changes, one is that for every register, I've also put in a define, and the other is that I comment out everything else that isn't relavant to the header files instead of just omitting them. Here's the code. If anyone finds any bugs, please tell me and I'll submit a fix. Also, Pavel, if you think this is useful, perhaps create a link for it on your site somewhere? File: inc2boosth.pl #!/usr/bin/perl -w # Project : inc2boosth v1.0 use strict; sub ProcessINC($); my $directoryOfINCs="C:\\progra~1\\MPLAB IDE\\MCHIP_Tools\\"; my $outputDir="c:\\progra~1\\sourceboost\\include\\"; opendir(INCDIR, $directoryOfINCs); while (defined(my $fileName = readdir(INCDIR))) { if ( ($fileName ne ".") && ($fileName ne "..") ) { # only process p12*.inc p16*.inc and p18*.inc files if ($fileName =~ m/^p(12|16|18).+[.]inc$/i) { ProcessINC($directoryOfINCs . $fileName); } } } closedir(INCDIR); sub ProcessINC($) { my $thisFile = shift; open (INCFILE, "<" . $thisFile) or die "Couldn't open $thisFile\n"; $thisFile =~ m/([^\\]+)[.][^.]+$/; open (HFILE, ">" . $outputDir . $1 . ".h") or die "Couldn't create $1\n"; my $indentCount = 0; my $isRegisterBlock = 0; while (<INCFILE>) { my $currentLine = $_; chomp $currentLine; # wipe out any trailing whitespace $currentLine =~ s/[\s\t]+$//g; # if comments exist anywhere in the line, convert to C-Style comment type if ($currentLine =~ m/\;/) { # replace the first semicolon with /* $currentLine =~ s/\;/\/\*/; # append a */ to the end of the line $currentLine .= " */"; } # if entire line is a comment pass it through if ($currentLine =~ m/^[\s\t]*\/\*.*\*\/$/) { #Check to see if we're in the register #block and set the flag appropriately if ($currentLine =~ m/Register/i) { $isRegisterBlock=1; } else { $isRegisterBlock=0; } print (HFILE $currentLine . "\n"); } # if line is blank, pass it through elsif ($currentLine =~ m/^$/) { print (HFILE "\n"); next; } # if line contains a IFDEF/IFNDEF statement, convert to c-style elsif ($currentLine =~ m/(IFDEF|IFNDEF)[\s\t]+([^\s\t]+)(\/?.*)$/) { print (HFILE "\t" x $indentCount . "#" . $1 . "\t" . $2); if ($3 ne "") { print (HFILE "\t" . $3); } print (HFILE "\n"); $indentCount++; } # if line contains a ENDIF statement, convert to c-style elsif ($currentLine =~ m/ENDIF[\s\t]*(\/?.*)$/) { $indentCount--; print (HFILE "\t" x $indentCount . "#ENDIF"); if ($1 ne "") { print (HFILE "\t" . $1); } print (HFILE "\n"); } # if line contains a DEFINE/UNDEFINE statement without a value, pass it through elsif ($currentLine =~ m/#(DEFINE|UNDEFINE)[\s\t]+([^\s\t\/]+)(\/?.*)$/i) { my $temp = $1; $temp =~ tr/[a-z]/[A-Z/; print (HFILE "\t" x $indentCount . "#" . $temp . "\t" . $2); if ("" ne $3) { print (HFILE "\t" . $3); } print (HFILE "\n"); } # if line contains a DEFINE statement with a value, convert to c-style elsif ($currentLine =~ m/#DEFINE[\s\t]+([^\s\t\/]+)(.*)$/i) { my $rawValue = $1; my $extraData = $2; print (HFILE "\t" x $indentCount . "#define\t"); if ($rawValue =~ m/^H'([^']+)'$/) { print (HFILE "0x$1"); } if ($extraData ne "") { print (HFILE "\t" . $extraData); } print (HFILE "\n"); } # if line contains " EQU ", convert to c-style DEFINE elsif ($currentLine =~ m/^([^\s\t]+)[\s\t]+EQU[\s\t]*([a-fA-F0-9Hh']+)(\/?.*)$/) { my $name = $1; my $rawValue = $2; my $extraData = $3; if ($isRegisterBlock == 0) { print (HFILE "\t" x $indentCount . "#define\t" . $name . "\t"); if ($rawValue =~ m/^[Hh]'([^']+)'$/) { print (HFILE "0x$1"); } elsif($rawValue =~ m/^([0-9A-Fa-f]+)$/i) { print (HFILE "0x$1"); } if ($extraData ne "") { print (HFILE "\t" . $extraData); } print (HFILE "\n"); } #if we're part of the register block #create special char ToLower(variable)@location lines too if ($isRegisterBlock == 1) { $name =~ tr/[A-Z]/[a-z]/; print (HFILE "\t" x $indentCount . "char " . $name . "@"); if ($rawValue =~ m/^[Hh]'([^']+)'$/) { print (HFILE "0x$1;"); } elsif($rawValue =~ m/^([0-9A-Fa-f]+)$/i) { print (HFILE "0x$1;"); } if ($extraData ne "") { print (HFILE "\t" . $extraData); } print (HFILE "\n"); } } # if line contains INCLUDE, rename the include file to use the .h extension elsif ($currentLine =~ m/INCLUDE[\s\t]+([<"])([^>]+)([>"])(.*)$/) { my $openChar = $1; my $incFile = $2; my $closeChar = $3; my $extraData = $4; $incFile =~ m/^([^.]+)/; print (HFILE "\t" x $indentCount . "#include " . $openChar . $incFile . ".h" . $closeChar); if ($extraData ne "") { print (HFILE "\t" . $extraData); } print (HFILE "\n"); } # else, it probably isn't anything we can use, so comment it out. # this includes: #(LIST|NOLIST|__MAXRAM|__BADRAM|MESSG|__MAXROM|__BADROM) else { print (HFILE "/*\t" . $currentLine . " */\n"); } } close (INCFILE); close (HFILE); }
  12. Exactly which standard will the BoostC compiler be based on? I've noticed there are a few standards for C, the latest, I believe, to be C99. One problem I see looming is the size of the built-in types... depending on the platform, an int can be 16 bits, or 32 bits.. same goes with the others... how long is a long? The C9X standard includes some header files that typedef the built-in types to include the bits as part of the name... so instead of int we'd use INT16... There are some other nice additions that I'd like to see included too, if possible. Here's a web site that does a nice job of listing some of the improvements: http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html
  13. I would have edited this into my previous post, but it still needs to be "moderated" so I can't access it. #include <system.h> struct ConvertThis { int arrayOne[15]; int *pArrayTwo[15]; }; void main() { struct ConvertThis ArrayConvertThis[3]; struct ConvertThis *pArrayConvertThis[3]; int i,j; i=0; j=1; pArrayConvertThis[i]->pArrayTwo[j] = &(pArrayConvertThis[i]->arrayOne[j]); (ArrayConvertThis + i)->pArrayTwo[j] = &(ArrayConvertThis[i].arrayOne[j]); } The line: (ArrayConvertThis + i)->pArrayTwo[j] = &(ArrayConvertThis.arrayOne[j]); gets the errors: convertthis.c(17:2): error: failed to generate expression convertthis.c(17:39): error: failed to generate expression This error post was for 1.7alpha too
  14. Hey Pavel, This code compiles fine with GCC. #include <system.h> struct ConvertThis { int arrayOne[15]; int *pArrayTwo[15]; }; void main() { struct ConvertThis *pArrayConvertThis[3]; int i,j; i=0; j=1; pArrayConvertThis[i]->pArrayTwo[j] = &(pArrayConvertThis[i]->arrayOne[j]); } The error: compilertest.c(15:37): error: can't convert 'struct struct ConvertThis**' to 'signed int*' If I replace the 'i's and 'j's with their actual values, things compile correctly. Btw, in case you were wondering, these are the flags I use with gcc: -Wall -W -O -Wno-div-by-zero -Wdeclaration-after-statement -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wpadded -Wredundant-decls -Wnested-externs -Wunreachable-code -Winline -Wlong-long -pedantic -ansi -funsigned-char Oops.. noticed that the error I posted was for something else.. I've edited this document to show the correct error. Also, this is for 1.7Alpha
  15. Hey Dave, Think you could change the stack error too reflect the limitations of the target too? I remember getting a stack error when I was trying to choak the compiler, but I wasn't certain if this was the compiler complaining about its' own stack, or if it was complaining about the stack limits of the target. After looking up the specs of the selected target, I realized that the error was probably due to the max of 8 stacks availiable to the target and NOT the compiler.
  16. Dave, Your answer looks to me to be the best solution to his problem, but my previous explanation was trying to answer why his code didn't work. In the headers, things like "portb" and "trisb" only show up in the headers as: char portb@0x0006; char trisb@0x0086; Since the preprocessor doesn't know about chars, those lines in the headers are skipped over, and the preprocessor is left with names with no associated values. Normally this is just fine.. simply leave the replaced names and let the compiler complain if that name isn't declared. The problem that SvendW ran into was how #IF works: While he thought: #if portb == porta was really comparing the strings: if "portb" == "porta" it was really comparing the values that those strings were defined as. Since neither was actually defined as anything the code translated to: nothing == nothing which would always equate to true. This was what I was trying to convey.
  17. Current, we can use the @ operator to assign a specific address to a variable without having to use pointers or indirection: char porta@0x5; Any chance of being able to expand it to do something like this? char outPort@&porta; void main() { outPort=0; }
  18. with GCC I can use the -E flag to have it only show me the code after the preprocessor has had its' way with the code. Any chance we can get this added for Boostc?
  19. try adding a "-D portb" to your compiler line and see what happens. Understand that the preprocessor only does text substitution... if porta or portb aren't previously defined through either a compiler directive, or through the source/headers using #define, then your code will look like this: #define PORTA porta (since porta isn't defined, neither will PORTA) #define PORTB portb (since portb isn't defined, neither will PORTB) #define PortOUT PORTB (since PORTB wasn't defined, neither will PortOUT) #if PortOUT == PORTA (this translates to if NOTHING == NOTHING) which means that it will always be true. by adding that "-D portb" for the compiler, you've defined portb (it doesn't matter WHAT it's defined to). Since portb is defined, #define PORTB portb will work, and so the rest of your code should follow as expected. At least it should if I understand this stuff correctly.... Oops.... I just tried the -D option and the compiler gave back the error: "warning: unrecognized command line agrument '-D', skipped" My advice was after seeing this: Useage: boostc.pic16.exe [options] files Options: -t name target processor (default name=PIC16F628) -On optimization level (default n=1) n=0 - optimization turned off n=1 - optimization turned on -Wn warning level (default n=1) n=0 - no warnings n=1 - some warnings n=2 - all warnings -di debug inline code (default off) -D name define 'name' -v verbose mode turned on (default off) So I guess the -D hasn't been implimented yet.
  20. Hey SvendW, I'm curious.. for the targets where there is only one port, does "portb" even exist in the header for that target?
  21. I think changing this line: if (m/#define\s*([^\s]+)\s*(0x[a-fA-F0-9]{4})$/) to if (m/#define\s*([^\s]+)\s*(0x[a-fA-F0-9]{1,4})$/) should fix that.
  22. The expression "cout << DoSomething(myValue);" doesn't have any destination and doesn't change any variable in the code. That's why compiler optimizes it out. This optimization happens at parsing stage when variables aren't known yet. This is why you don't get any error if cout isn't declared. Regards, Pavel <{POST_SNAPBACK}> Hey Pavel, There's a bug in the example code above, but regardless, DoSomething(myValue); changes a global variable in the above code. The part that was supposed to be optimized out was the part where the return value of DoSomething is discarded, not the call to DoSomething. GCC shows things to work as expected. The asm generated by boostc cuts out the entire Dosomething function. Here's "correct" example code: #include <system.h> //#include <stdio.h> char globalValue = 0; char DoSomething(char aValue) { globalValue = aValue + 1; return 'A'; } void main() { char myValue = globalValue; int cout; cout << DoSomething(myValue); if (0 == globalValue) { /* whoops, call to DoSomething was incorrectly optimized out. */ // this breakpoints in SourceBoostIDE myValue = globalValue; // this would print a 0 but it doesn't in linux // printf("%d", globalValue); } else { myValue = globalValue; // This executes in linux // and prints a 1 to the screen. // printf("%d", globalValue); } }
  23. Note the capital C in the second argument for your define: 58 #define i2c_SSPIF i2c_SSPIF_PIR, i2C_SSPIF_BIT --------------------------------------------------^ It's lowercase here: 74 clear_bit(i2c_SSPIF_PIR,i2c_SSPIF_BIT); ----------------------------------^ I wrote some example code with the correct case and it compiles just fine in GCC and Boostc: #define i2c_SSPIF_PIR 2 #define i2c_SSPIF_BIT 1 int clear_bit(int, int); #define i2c_SSPIF i2c_SSPIF_PIR, i2c_SSPIF_BIT void main() { clear_bit(i2c_SSPIF_PIR, i2c_SSPIF_BIT); clear_bit(i2c_SSPIF); } int clear_bit(int one, int two) { return (one + two); }
  24. Haha, Thanks Dave, that one IS the easiest to read.
  25. I've written a perl script to "correct" all those header files. (This assumes that the actual variable names weren't actually truncated in the original headers): #!/usr/bin/perl -w use strict; my $currentFile; my $currentDir = "c:\\program files\\SourceBoost\\include\\"; opendir(DIR, $currentDir) or die "can't opendir $currentDir: $!"; while (defined($currentFile = readdir(DIR))) { if ($currentFile =~ m/(boostc.h|rand.h|system.h)/i) { next; } if ($currentFile =~ m/\.h$/) { open(DEFINE_IN, "<" . $currentDir . $currentFile) or die "Couldn't read $currentFile: $!"; my @fileBuffer; while (<DEFINE_IN>) { chomp; # delete any extra spaces at the end of each line s/\s+$//; if (m/^[^\/].*[^;]$/) { s/\s{2,}/\t/g; } else { s/\s{2,}//g; } if (m/#define\s*([^\s]+)\s*(0x[a-fA-F0-9]{4})$/) { push (@fileBuffer, "#define\t$1\t$2\n"); } else { push (@fileBuffer, ($_ . "\n")); } } close(DEFINE_IN); open(DEFINE_OUT, ">" . $currentDir . $currentFile) or die "Couldn't write to $currentFile: $!"; foreach(@fileBuffer) { print DEFINE_OUT; } close(DEFINE_OUT); } } closedir(DIR); you can get the perl interpreter for windows here: http://downloads.activestate.com/ActivePer...MSWin32-x86.msi
×
×
  • Create New...