Programmatically compiling (perl -c) a Perl file

As a basic quality check against a needy code base, I want to ensure that every file at least compiles (perl -c). Some don't because they are require'd at runtime by others and depend on them to have set their global variables. And some die due to stuff in their BEGIN blocks, which should go to INIT.

I could certainly collect a list of file and call "perl -c" on each of them.

However, I'm curious: Is it possible to invoke the compiler programmatically using the O and B::* modules? How exactly? Haven't discovered this in:

* perlcompile
* O
* B

Feel free to redirect me to a more appropriate forum. Thanks.
--
Michael Ludwig
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Programmatically compiling (perl -c) a Perl file

Well, might be possible with those hacks. However there would be some more simpler solutions to this if we just need to compile check a list of perl files.
For example a file 'a' consisting a statement of requiring file 'b' at runtime, compile checking file a with conditions which makes file b execute does serve the purpose. might sound towards code coverage or static analysis tools. some kind of custom test scenarios scripted down can also come as a rescue...


Regards & Thanks mailto: senapati2001@yahoo.com


--- On Wed, 8/4/10, Ludwig, Michael wrote:

> From: Ludwig, Michael
> Subject: Programmatically compiling (perl -c) a Perl file
> To: activeperl@listserv.ActiveState.com
> Date: Wednesday, August 4, 2010, 12:57 PM
> As a basic quality check against a
> needy code base, I want to ensure that every file at least
> compiles (perl -c). Some don't because they are require'd at
> runtime by others and depend on them to have set their
> global variables. And some die due to stuff in their BEGIN
> blocks, which should go to INIT.
>
> I could certainly collect a list of file and call "perl -c"
> on each of them.
>
> However, I'm curious: Is it possible to invoke the compiler
> programmatically using the O and B::* modules? How exactly?
> Haven't discovered this in:
>
> * perlcompile
> * O
> * B
>
> Feel free to redirect me to a more appropriate forum.
> Thanks.
> --
> Michael Ludwig
> _______________________________________________
> ActivePerl mailing list
> ActivePerl@listserv.ActiveState.com
> To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
>




_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: Programmatically compiling (perl -c) a Perl file

> -----Original Message-----
> From: p sena

> Well, might be possible with those hacks. However there would be some
> more simpler solutions to this if we just need to compile check a list
> of perl files.
> For example a file 'a' consisting a statement of requiring file 'b' at
> runtime, compile checking file a with conditions which makes file b
> execute does serve the purpose.

Thanks, P Sena. Guess you're right. I want to make sure the files I'm
dealing with do each compile individually without relying on others to
have declared their global variables. If I have only one process to
check a list of Perl files, crappy stuff might still compile because of
other stuff having initialized it from afar.

> some kind of custom test scenarios scripted down can also come as a
> rescue...

Getting each file to compile individually is my first step in a series
of measures to raise code quality. Then, we can think about more
advanced things like testing or perlcritic. You might have better
ideas - if so, please let me know. Thanks!

--
Michael Ludwig
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: Programmatically compiling (perl -c) a Perl file

It also depends on how you declare the globals in the file and how you use them in another file from where you require the first file.
Use strict and warnings enabled or are they already have it or not ? if not how are the compiled results and if yes how are they?

Generate a kind of test frame so as to write and execute test scripts for each perl file from within the framework. These individual test scripts would comprise of various test cases/scenarios.
Formulate the case/scenarios such that it tests all scenes whetrein some globals gets used and sometimes not used may be.
Also, in same lines the scenarios where at run time one file is required at times and not required sometimes.
Take look at do and eval from perldoc and see if it helps somewhere from a to z. The globals much in question, can be taken care from each individual test script and similar other things if exists.
There may be more than one test script corresponding to a perl file (original perl program to be tested). This can be done sequentally or parallely and depends on situations. RUn framework and observer/collect results/reports...


Regards & Thanks mailto: senapati2001@yahoo.com


--- On Thu, 8/5/10, Ludwig, Michael wrote:

> From: Ludwig, Michael
> Subject: RE: Programmatically compiling (perl -c) a Perl file
> To: activeperl@listserv.ActiveState.com
> Date: Thursday, August 5, 2010, 8:39 PM
> > -----Original Message-----
> > From: p sena
>
> > Well, might be possible with those hacks. However
> there would be some
> > more simpler solutions to this if we just need to
> compile check a list
> > of perl files.
> > For example a file 'a' consisting a statement of
> requiring file 'b' at
> > runtime, compile checking file a with conditions which
> makes file b
> > execute does serve the purpose.
>
> Thanks, P Sena. Guess you're right. I want to make sure the
> files I'm
> dealing with do each compile individually without relying
> on others to
> have declared their global variables. If I have only one
> process to
> check a list of Perl files, crappy stuff might still
> compile because of
> other stuff having initialized it from afar.
>
> > some kind of custom test scenarios scripted down can
> also come as a
> > rescue...
>
> Getting each file to compile individually is my first step
> in a series
> of measures to raise code quality. Then, we can think about
> more
> advanced things like testing or perlcritic. You might have
> better
> ideas - if so, please let me know. Thanks!
>
> --
> Michael Ludwig
> _______________________________________________
> ActivePerl mailing list
> ActivePerl@listserv.ActiveState.com
> To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
>




_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: Programmatically compiling (perl -c) a Perl file

p sena schrieb am 06.08.2010 um 08:54 (-0700):
> It also depends on how you declare the globals in the file and how you
> use them in another file from where you require the first file.
> Use strict and warnings enabled or are they already have it or not ?
> if not how are the compiled results and if yes how are they?

Thanks once more, P Sena. Here's the situation some of the files are in:

\,,,/
(o o)
------oOOo-(_)-oOOo------
michael@wladimir:~ :-) cat a.pl
use strict;
use vars '$x';
$x = 1;
require 'b.pl';
bla();
michael@wladimir:~ :-) cat b.pl
use strict;
sub bla { print ++$x, "\n" }
1;
michael@wladimir:~ :-) perl a.pl
2
michael@wladimir:~ :-) perl -c b.pl
Global symbol "$x" requires explicit package name at b.pl line 2.
b.pl had compilation errors.
-------------------------

That's pretty bad, and obviously it cannot stay like this. There's lots
of other things to do, but getting individual files to pass a simple
perl -c test is my first priority.

I guess my interest in possible compiler options is rather theoretical.
I can achieve what I want with what I already know.

> Generate a kind of test frame so as to write and execute test scripts
> for each perl file from within the framework. These individual test
> scripts would comprise of various test cases/scenarios.

Test::More plus File::Find plus perl -c, for starters.

> Formulate the case/scenarios such that it tests all scenes whetrein
> some globals gets used and sometimes not used may be.

Yeah. I hope to eliminate most of the globals.

> Also, in same lines the scenarios where at run time one file is
> required at times and not required sometimes.
> Take look at do and eval from perldoc and see if it helps somewhere
> from a to z. The globals much in question, can be taken care from each
> individual test script and similar other things if exists.
> There may be more than one test script corresponding to a perl file
> (original perl program to be tested). This can be done sequentally or
> parallely and depends on situations. RUn framework and
> observer/collect results/reports...

Thanks for your suggestions, much appreciated!

Best,
--
Michael Ludwig
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: Programmatically compiling (perl -c) a Perl file

--- On Thu, 8/5/10, Ludwig, Michael wrote:

> From: Ludwig, Michael
> Subject: RE: Programmatically compiling (perl -c) a Perl file
> To: activeperl@listserv.ActiveState.com
> Date: Thursday, August 5, 2010, 8:39 PM
> > -----Original Message-----
> > From: p sena
>
> > Well, might be possible with those hacks. However
> there would be some
> > more simpler solutions to this if we just need to
> compile check a list
> > of perl files.
> > For example a file 'a' consisting a statement of
> requiring file 'b' at
> > runtime, compile checking file a with conditions which
> makes file b
> > execute does serve the purpose.
>
> Thanks, P Sena. Guess you're right. I want to make sure the
> files I'm
> dealing with do each compile individually without relying
> on others to
> have declared their global variables. If I have only one
> process to
> check a list of Perl files, crappy stuff might still
> compile because of
> other stuff having initialized it from afar.
>
> > some kind of custom test scenarios scripted down can
> also come as a
> > rescue...
>
> Getting each file to compile individually is my first step
> in a series
> of measures to raise code quality. Then, we can think about
> more
> advanced things like testing or perlcritic. You might have
> better
> ideas - if so, please let me know. Thanks!
>
> --
> Michael Ludwig

It also depends on how you declare the globals in the file and how you use them in another file from where you require the first file.
Use strict and warnings enabled or are they already have it or not ? if not how are the compiled results and if yes how are they?

Generate a kind of test frame so as to write and execute test scripts for each perl file from within the framework. These individual test scripts would comprise of various test cases/scenarios.
Formulate the case/scenarios such that it tests all scenes whetrein some globals gets used and sometimes not used may be.
Also, in same lines the scenarios where at run time one file is required at times and not required sometimes.
Take look at do and eval from perldoc and see if it helps somewhere from a to z. The globals much in question, can be taken care from each individual test script and similar other things if exists.
There may be more than one test script corresponding to a perl file (original perl program to be tested). This can be done sequentally or parallely and depends on situations. RUn framework and observer/collect results/reports...

Thanks,
p sena




_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs