Usually I've found that when someone says "yes, I really need to do this" and doesn't provide an explanation, further digging often reveals that the person's problem has a much simpler and better solution than the proposed one.

So, I have to ask "why". Quite often, it turns out that a person's reasons for doing something, once explained, leads to different and better solutions for what they are trying to accomplish. Further, if you're just doing this to protect your intellectual work, you may wish to consider a programming language more suitable for that than Perl. In the Perl community, you are given a programming language and lots and lots of help for free. As a result, if you turn around and hide your source code, it's often frowned upon.

Also, Perl compilers are generally not terribly good. I don't know why your code is up to 20MB, but you should be aware that the entire Perl interpreter is embedded in the compiled version (which is required, due to the way Perl works).

So, if you explain why you want to do this, maybe we can help you find an easier solution.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

In the Perl community, you are given a programming language and lots and lots of help for free. As a result, if you turn around and hide your source code, it's often frowned upon.

I hear a lot of people complaining about businesses failing to adopt Perl. These people give many reasons for why this is, ranging from lack of certifications to the fact that certain other languages have huge corporations backing them. These are all valid, but often what is left out is the attitude of many members of the Perl community.

I agree with you that there are often far better options than compiling Perl, but the attitude that developers owe their code to the community does not benefit Perl or free software at all, it only serves to prevent some businesses from considering Perl as an option.

cjf++

Thanks for clearing up a rather ambiguous point that I raised and inadvertently suggested that I agree with. I was just stating the position that many adopt. Many strongly object to trying to "hide" source merely to hide the source.

Personally, I don't have strong feelings on it one way or another. I do feel strongly that if someone takes from the community, one should give back. I don't think this necessarily means giving back one's code. Donating to the Perl foundation or hanging out at the Monastery and helping other's are two very worthwhile methods of giving back.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

$ perldoc -q compile
Found in /usr/lib/perl5/5.6.1/pod/perlfaq3.pod
       How can I compile my Perl program into byte code or C?
[download]

metadoktor

"The doktor is in."

Keep in mind that your script will need libraries, etc. to run as an app.

I have the activestate devkit for win32 which has perlapp (there are versions for solaris, hpux and linux) and for my script of 7K it turned it into almost 1 meg app. I am not sure the size of a Unix version would produce.

As for solutions, I don't think there are any better ways than those you have tried. Compiling any script-type (or interpreted) language that isn't intended to be made into binaries has always had these problems, as far as I can tell. I even remember there being BASIC to machine code compilers for the good old Commodore 64, and those had the exact same problem.

I think the basic problem is that you have a language that is (more or less, I know it isn't really true) interpreted on the fly, with the commands in the program being "references" to built-in functions in the interpreter, which are called and something happens. This is very hard to translate into effecient c or assembler code, usually the realistic approach is to either embed the whole interpreter and still call the same things, or replace each call with the corresponding function from the interpreter. Needless to say, this isn't gonna be very optimized - but at the same time, code that wasn't meant to be compiled is very hard to guess the optimized intention of.

As mentioned in perlrun, you have the -u option, and could use the undump program, but according to the example, that gets just as bloated, or worse. It is also very much deprecated in favour of the c-compiler alternatives you have already tried.

In short, if you need to hide your code for some reason, perl might not be the right tool for you. It is constructed with quite the opposite intentions, and it shows. On the other hand, if this is a special ocassion, is 20MB really that much? If it is just this program, this one time, just go for it if it works. It might feel silly to have 20MB worth of program printing "Hello world", but if it does the job... disk is cheap. :)

Also have a look at Can I get compiled code in Perl like in Java(class file), I seem to recall some good and related answers there.

Not really a response to the question, but...

Python will let you compile to bytecode, then save the bytecode in another file. Perl also compiles to bytecode, so wouldn't it be possible for perl to do something along the same lines?

This would mean you would still need to install perl to run a compiled perl script, but it would also mean that people could distribute scripts or modules without having to worry about others being able to see their source code. (At least no more danger than being able to see the source of a java app distributed as a .class file.)

Perhaps this is something that will be possible with Perl 6?

Currently, this is not realistic for Perl5. Because of eval, the /e switch on substitutions, and other language features, Perl requires that the Perl interpreter always be available to call upon, if need be.

A experimental JIT compiler is being developed for Parrot, so I do expect that Perl 6 will offer some fantastic possibilities in this area.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.