Verilog-Perl

I don't think anyone else has tried ActiveState since then. The hard parts are first to get bison and flex, and a C++ compiler (mingw should be fine.) Then look at an existing C++ based Perl module to see how active state does it. (Inline::CPP might be one possibility.)

If you have problems with flex/bison you should be able to run a make on linux/cygwin, and then copy all the generated files over to Windows.

Ask if you run into trouble!

Hi again Wilson,

I managed to find all the necessary build tools you mentioned that I needed. So, I downloaded and installed all the following tools (versions in parentheses):

MinGW (5.1.4 using g++ version 3.4.5) GnuWin32 Bison (2.1) GnuWin32 Flex (2.5.4a-1) Dmake (4.11-20080107-SHAY) ActivePerl (5.10.0.1004)

I also downloaded the latest source files for Verilog-Perl (3.044). I extracted the files for the Verilog-Perl sources onto a folder on my desktop. Then I added a few necessary pathnames to my OS environment variables for the tools that were downloaded.

I next followed the instructions in the README file included with the Verilog-Perl sources. As you'll see in the included logfile, the first step in the process ("perl makefile.pl") completed without problem. All was good to go.

Next I attempted the "make" step and, although it started off well, it hit a problem, returned a couple errors, and the script stopped. The first error returned was a command that wasn't recognized and it advised to upgrade to a more recent version of Bison. The one I installed is newer than what it recommended.

Anyhow, I'd really appreciate if you can you take a look at the logfile I attached and give some guidance on what I can try next.

Thanks again for your help.

-Jose

This line should run perl to start the "bisonpre" command in the Parser directory, and run bison.

C:\Perl\bin\perl.exe bisonpre --yacc bison --debug --verbose --d -k VParseBison.y bisonpre -p VParseBison -o VParseBison.c

The "unknown parameter" makes me think that active state doesn't parse arguments the same way as normal perl. Can you "cd Parser" and try this command standalone? You may want to add to the top of bisonpre:

use Data::Dumper; print Dumper(\@ARGV);

The first argument should be "--yacc".

Hi Wilson,

I tried what you asked ...

1) I edited the "bisonpre" file in the \Verilog-Perl\Parser\ directory and added the line you asked just after the "require ..." line.

2) I invoked the command you asked within the Parser subdirectory at a Windows command prompt. I have attached a logfile showing the results of that command.

Thanks once again, Jose

Try this.

I edited the makefile as you suggested, but it returned a message saying that 'rm' is not a recognized command. This was also the first error message in my original "dmake" attempt. So, I did some searching and the ActiveState documentation stated that the rm -r* commands should instead use "rmtree" to delete directory trees. I'm going to go ahead and replace any 'rm -rf' commands with the 'rmtree' function and see how that works. Hopefully that will eliminate the downstream errors that also occurred.

Just in case, I'm attaching a log of the latest errors. Let me know what you think of my approach or if I've misinterpreted the errors.

Will send an update later on this attempt either way.

-Jose

P.S. If I edit one of the makefiles, should I start the process from the very beginning ... i.e. the "perl makefile.pl" command at the root directory?

I commented out any lines in the three makefile.pl files with the "-rm -rf" flags and replaced those lines with the "rmtree" command. It did not work, and failed at roughly the same point as with the "-rm -rf" flags.

Now, I thought those lines were trying to recursively remove directories and the files in those directories. Am I wrong?

Each of the "-rm -rf" lines usually contains various parameters, which appear to be expressions for types of files to remove. Would it be just as effective if I just used the "unlink" command on each of those parameters and the rmdir command on actual directories?

Are the "-rm -rf" lines being interpreted by perl, or are they intended to be executed by the OS, in which case I need to execute the equivalent windows commandline calls?

Thanks again in advance for any help anyone can provide.

-Jose

Addendum to my previous post ...

I forgot to mention that both the "-rm -rf" lines and the "rmtree" commands returned error messages stating "... is not recognized as an internal or external command, operable program, or batch file". In case that helps out.

Thanks! Jose

rm -rf is a shell command. (Rummage....)

Try replacing it with $(RM_RF). Or, try "del" with appropriate flags.

I tried your suggestion of replacing "-rm -rf" with $(rm_rf) and that seems to have gotten me past the previous problem. Now, the script ends during what I think is a compilation. At one point it returns an error message that VParseBison.c cannot be found in the Parser subdirectory. But VParseBison.c does exist. However, I noted the wording of the error message and note that the error message indicates that it cannot find "VParseBison.c." ... there is a period at the end. After looking through the makefiles, I notice that there are some lines that indicate extensions of the form ".c.i", ".c.s", and ".xs.c". At least that's how I interpret those lines, but I can't be sure. I'm attaching the three makefiles for your inspection.

For the main makefile, you can check lines 431, 437, and 455.

For the Parser makefile, note lines 316, 322, and 340.

For the Preproc makefile, note lines 305, 311, and 329.

Thanks once again, Jose

I added RM_RF to the GIT version and this will be in the next release. In your edits you need to use -$(RM_RF) note the minus and capitalization is different than what you sent, I think that's your issue.

BTW .c.i etc in the makefile is the Make language way of specifying a rule to convert .c to .i, that's normal.

Is there a flag or command that I can add to the makefile or while invoking dmake which will return the file and line # where it stopped executing? Sometimes I can figure it out, and other times not so much.

In the meantime I will make the change you suggested and try it out.

I don't know if there's a make flag to show where it stops, though there is a verbose flag. Check its manual.

I'm attaching the latest log. There are a couple of errors that dmake reports. I tried to do some investigation on them, but I wasn't sure how to winnow down the information I found because most of the info was tailored to specific implementations. One I found was due to a missing library definition in the *.c file.

Anyways, I hope it makes more sense to you.

Thanks, Jose

It's a known bug in the GCC you're using. Change the "-O2" in the Makefile to just "-O", or if that fails "-O0". The program will run slower, but better than nothing.