Loading ...
Sorry, an error occurred while loading the content.
 

[mp2] make test fails on Gentoo with CVS sources

Expand Messages
  • Haroon Rafique
    Hi, I recently checked out the most recent CVS sources for mp2. My system is Gentoo Linux with apache-2.0.45, perl v5.8.0. perl Makefile.PL MP_AP_PREFIX=/www
    Message 1 of 16 , Apr 22, 2003
      Hi,

      I recently checked out the most recent CVS sources for mp2. My system is
      Gentoo Linux with apache-2.0.45, perl v5.8.0.

      perl Makefile.PL MP_AP_PREFIX=/www
      make
      make test

      all work fine (except for one failure)
      apr/perlio.t 11 1 9.09% 7
      which I can trace later on.

      This is a straightforward case of all the apache stuff being under one
      tree /www. (I had hand-compiled apahce under /www in this case).

      However, Gentoo uses a different layout for apache2. One of the
      differences in the layout which is causing problem is that binaries are
      called /usr/sbin/apache2 and /usr/sbin/apxs2 (so on) and the modules are
      stored in /usr/lib/apache2. Gentoo has a package managment system called
      portage which has the following in the build file for mod_perl:

      perl Makefile.PL \
      PREFIX=/usr \
      MP_TRACE=1 \
      MP_DEBUG=1 \
      MP_AP_PREFIX=/usr \
      MP_USE_DSO=1 \
      MP_INST_APACHE2=1 \
      MP_APXS=/usr/sbin/apxs2 \
      CCFLAGS="${CFLAGS} -fPIC" \
      INSTALLDIRS=vendor

      After executing the above by hand, the file lib/Apache/BuildConfig.pm,
      contains the correct reference for:

      'MODPERL_AP_LIBEXECDIR' => '/usr/lib/apache2',

      Following that with a make, everything is fine. However, for some reason
      during the execution of the tests, make test gives the following error:

      **********************************************************************
      t/TEST -verbose=0
      /usr/sbin/apache2 -d /home/haroon/src/dist/cvs-src/modperl-2.0/t -f
      /home/haroon/src/dist/cvs-src/modperl-2.0/t/conf/httpd.conf -DAPACHE2
      using Apache/2.0.45 (prefork MPM)

      waiting for server to start: .Syntax error on line 27 of
      /home/haroon/src/dist/cvs-src/modperl-2.0/t/conf/httpd.conf:
      Invalid command 'TransferLog', perhaps mis-spelled or defined by a module
      not included in the server configuration
      !!!
      server has died with status 255 (t/logs/error_log wasn't created, start
      the server in the debug mode)
      make: *** [run_tests] Terminated
      **********************************************************************

      So, its complaining about TransferLog and the reason is that
      t/conf/httpd.conf contains none of the standard LoadModule statements for
      the regular apache modules. The LoadModule for perl_module is the only one
      present in that file.

      Anyone care to comment on the above?
      --
      Haroon Rafique
      <haroon.rafique@...>
    • Stas Bekman
      ... That s a known problem, thank you. (Happens only with perl w/o threads) ... Doesn t perl already supplise -fPIC? what s the output of: % perl -V:ccflags
      Message 2 of 16 , Apr 22, 2003
        Haroon Rafique wrote:
        > Hi,
        >
        > I recently checked out the most recent CVS sources for mp2. My system is
        > Gentoo Linux with apache-2.0.45, perl v5.8.0.
        >
        > perl Makefile.PL MP_AP_PREFIX=/www
        > make
        > make test
        >
        > all work fine (except for one failure)
        > apr/perlio.t 11 1 9.09% 7
        > which I can trace later on.

        That's a known problem, thank you. (Happens only with perl w/o threads)

        > This is a straightforward case of all the apache stuff being under one
        > tree /www. (I had hand-compiled apahce under /www in this case).
        >
        > However, Gentoo uses a different layout for apache2. One of the
        > differences in the layout which is causing problem is that binaries are
        > called /usr/sbin/apache2 and /usr/sbin/apxs2 (so on) and the modules are
        > stored in /usr/lib/apache2. Gentoo has a package managment system called
        > portage which has the following in the build file for mod_perl:
        >
        > perl Makefile.PL \
        > PREFIX=/usr \
        > MP_TRACE=1 \
        > MP_DEBUG=1 \
        > MP_AP_PREFIX=/usr \
        > MP_USE_DSO=1 \
        > MP_INST_APACHE2=1 \
        > MP_APXS=/usr/sbin/apxs2 \
        > CCFLAGS="${CFLAGS} -fPIC" \
        > INSTALLDIRS=vendor

        Doesn't perl already supplise -fPIC? what's the output of:

        % perl -V:ccflags -V:cccdlflags

        Why do you need MP_AP_PREFIX? Doesn't apxs already finds everything mod_perl
        needs?

        > After executing the above by hand, the file lib/Apache/BuildConfig.pm,
        > contains the correct reference for:
        >
        > 'MODPERL_AP_LIBEXECDIR' => '/usr/lib/apache2',
        >
        > Following that with a make, everything is fine. However, for some reason
        > during the execution of the tests, make test gives the following error:
        >
        > **********************************************************************
        > t/TEST -verbose=0
        > /usr/sbin/apache2 -d /home/haroon/src/dist/cvs-src/modperl-2.0/t -f
        > /home/haroon/src/dist/cvs-src/modperl-2.0/t/conf/httpd.conf -DAPACHE2
        > using Apache/2.0.45 (prefork MPM)
        >
        > waiting for server to start: .Syntax error on line 27 of
        > /home/haroon/src/dist/cvs-src/modperl-2.0/t/conf/httpd.conf:
        > Invalid command 'TransferLog', perhaps mis-spelled or defined by a module
        > not included in the server configuration
        > !!!
        > server has died with status 255 (t/logs/error_log wasn't created, start
        > the server in the debug mode)
        > make: *** [run_tests] Terminated
        > **********************************************************************
        >
        > So, its complaining about TransferLog and the reason is that
        > t/conf/httpd.conf contains none of the standard LoadModule statements for
        > the regular apache modules. The LoadModule for perl_module is the only one
        > present in that file.
        >
        > Anyone care to comment on the above?

        TransferLog is defined by mod_log_config.c, which is built in by default. You
        can check whether you have it with:

        % /usr/sbin/apache2 -l |grep log_config

        Or was it compiled as DSO and you have it in the dir where all DSO modules are?

        % find `/usr/sbin/apxs2 -q libexecdir` |grep log_config


        __________________________________________________________________
        Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
        http://stason.org/ mod_perl Guide ---> http://perl.apache.org
        mailto:stas@... http://use.perl.org http://apacheweek.com
        http://modperlbook.org http://apache.org http://ticketmaster.com
      • Haroon Rafique
        On Today at 10:11am, SB= Stas Bekman wrote: SB SB perl Makefile.PL SB PREFIX=/usr SB MP_TRACE=1 SB
        Message 3 of 16 , Apr 23, 2003
          On Today at 10:11am, SB=>Stas Bekman <stas@...> wrote:

          SB> >
          SB> > perl Makefile.PL \
          SB> > PREFIX=/usr \
          SB> > MP_TRACE=1 \
          SB> > MP_DEBUG=1 \
          SB> > MP_AP_PREFIX=/usr \
          SB> > MP_USE_DSO=1 \
          SB> > MP_INST_APACHE2=1 \
          SB> > MP_APXS=/usr/sbin/apxs2 \
          SB> > CCFLAGS="${CFLAGS} -fPIC" \
          SB> > INSTALLDIRS=vendor
          SB>
          SB> Doesn't perl already supplise -fPIC? what's the output of:
          SB>
          SB> % perl -V:ccflags -V:cccdlflags
          SB>

          Hi Stas,

          ccflags='-DPERL5 -fno-strict-aliasing -D_LARGEFILE_SOURCE
          -D_FILE_OFFSET_BITS=64';
          cccdlflags='-fpic';

          The above perl Makefile.PL line was not created by me. It was created by
          the Gentoo package maintainers. I'm just trying to make it pass the "make
          test". The Gentoo people just comment out the "make test" part of the
          package and install without testing.

          SB> Why do you need MP_AP_PREFIX? Doesn't apxs already finds everything
          SB> mod_perl needs?
          SB>

          See above note.

          SB> TransferLog is defined by mod_log_config.c, which is built in by
          SB> default. You can check whether you have it with:
          SB>
          SB> % /usr/sbin/apache2 -l |grep log_config
          SB>
          SB> Or was it compiled as DSO and you have it in the dir where all DSO
          SB> modules are?
          SB>
          SB> % find `/usr/sbin/apxs2 -q libexecdir` |grep log_config

          I think I didn't explain myself properly.

          I am working with 2 apaches here. Both apaches have DSO modules.

          1) is hand-compiled and installed in /www and everything apache related is
          underneath /www. Building mod_perl for that case is trivial
          perl Makefile.PL MP_AP_PREFIX=/www
          Similarly, make test runs beautifully.

          2) is installed by Gentoo package management system, and has a
          non-standard apache layout. Binaries are in /usr/sbin (as apxs2 and
          apache2), shared modules are in /usr/lib/apache2. Building mod_perl for
          that case is trivial too and I have it running on my machine with the
          non-standard layout using the following configuration as noted in my
          original email (I think I missed the ${D} last time in the 2nd line):
          perl Makefile.PL \
          PREFIX=${D}/usr \
          MP_TRACE=1 \
          MP_DEBUG=1 \
          MP_AP_PREFIX=/usr \
          MP_USE_DSO=1 \
          MP_INST_APACHE2=1 \
          MP_APXS=/usr/sbin/apxs2 \
          CCFLAGS="${CFLAGS} -fPIC" \
          INSTALLDIRS=vendor
          The only problem is that "make test" complains about TransferLog and
          never goes beyond that point.

          So, given the facts that both of these use DSO modules and both can be
          installed and run just fine, what can we do to have "make test" be
          successful in the 2nd case (non-standard apache layout)?

          I hope I have given you enough information about my problem. Again, to
          summarize, while building mod_perl for the non-standard apache layout,
          during "make test" the test complains about the TransferLog directive
          which, in turn, I have been able to trace to the fact that none of the
          LoadModule lines are present in t/conf/httpd.conf. In contrast, while
          running the same "make test" for the /www apache, I could see lines like:

          LoadModule log_config_module "/www/modules/mod_log_config.so"

          So, what's causing the LoadModule lines to be absent from
          t/conf/httpd.conf when building against the Gentoo non-standard apache? I
          just don't know enough about the code in Apache-Test directory whereas you
          will be able to spot this relatively quickly.

          Thanks for your help,
          --
          Haroon Rafique
          <haroon.rafique@...>
        • Stas Bekman
          ... Still, why do you supply CCFLAGS= ${CFLAGS} -fPIC ? Doesn t it work without it? Look at the generated Makefile it already includes -fpic (unless you need
          Message 4 of 16 , Apr 23, 2003
            Haroon Rafique wrote:
            > On Today at 10:11am, SB=>Stas Bekman <stas@...> wrote:
            >
            > SB> >
            > SB> > perl Makefile.PL \
            > SB> > PREFIX=/usr \
            > SB> > MP_TRACE=1 \
            > SB> > MP_DEBUG=1 \
            > SB> > MP_AP_PREFIX=/usr \
            > SB> > MP_USE_DSO=1 \
            > SB> > MP_INST_APACHE2=1 \
            > SB> > MP_APXS=/usr/sbin/apxs2 \
            > SB> > CCFLAGS="${CFLAGS} -fPIC" \
            > SB> > INSTALLDIRS=vendor
            > SB>
            > SB> Doesn't perl already supplise -fPIC? what's the output of:
            > SB>
            > SB> % perl -V:ccflags -V:cccdlflags
            > SB>
            >
            > Hi Stas,
            >
            > ccflags='-DPERL5 -fno-strict-aliasing -D_LARGEFILE_SOURCE
            > -D_FILE_OFFSET_BITS=64';
            > cccdlflags='-fpic';
            >
            > The above perl Makefile.PL line was not created by me. It was created by
            > the Gentoo package maintainers. I'm just trying to make it pass the "make
            > test". The Gentoo people just comment out the "make test" part of the
            > package and install without testing.

            Still, why do you supply CCFLAGS="${CFLAGS} -fPIC"? Doesn't it work without
            it? Look at the generated Makefile it already includes -fpic (unless you need
            -fPIC instead).

            > SB> Why do you need MP_AP_PREFIX? Doesn't apxs already finds everything
            > SB> mod_perl needs?
            > SB>
            >
            > See above note.
            >
            > SB> TransferLog is defined by mod_log_config.c, which is built in by
            > SB> default. You can check whether you have it with:
            > SB>
            > SB> % /usr/sbin/apache2 -l |grep log_config
            > SB>
            > SB> Or was it compiled as DSO and you have it in the dir where all DSO
            > SB> modules are?
            > SB>
            > SB> % find `/usr/sbin/apxs2 -q libexecdir` |grep log_config
            >
            > I think I didn't explain myself properly.
            >
            > I am working with 2 apaches here. Both apaches have DSO modules.
            >
            > 1) is hand-compiled and installed in /www and everything apache related is
            > underneath /www. Building mod_perl for that case is trivial
            > perl Makefile.PL MP_AP_PREFIX=/www
            > Similarly, make test runs beautifully.
            >
            > 2) is installed by Gentoo package management system, and has a
            > non-standard apache layout. Binaries are in /usr/sbin (as apxs2 and
            > apache2), shared modules are in /usr/lib/apache2. Building mod_perl for
            > that case is trivial too and I have it running on my machine with the
            > non-standard layout using the following configuration as noted in my
            > original email (I think I missed the ${D} last time in the 2nd line):
            > perl Makefile.PL \
            > PREFIX=${D}/usr \
            > MP_TRACE=1 \
            > MP_DEBUG=1 \
            > MP_AP_PREFIX=/usr \
            > MP_USE_DSO=1 \
            > MP_INST_APACHE2=1 \
            > MP_APXS=/usr/sbin/apxs2 \
            > CCFLAGS="${CFLAGS} -fPIC" \
            > INSTALLDIRS=vendor
            > The only problem is that "make test" complains about TransferLog and
            > never goes beyond that point.
            >
            > So, given the facts that both of these use DSO modules and both can be
            > installed and run just fine, what can we do to have "make test" be
            > successful in the 2nd case (non-standard apache layout)?
            >
            > I hope I have given you enough information about my problem. Again, to
            > summarize, while building mod_perl for the non-standard apache layout,
            > during "make test" the test complains about the TransferLog directive
            > which, in turn, I have been able to trace to the fact that none of the
            > LoadModule lines are present in t/conf/httpd.conf. In contrast, while
            > running the same "make test" for the /www apache, I could see lines like:
            >
            > LoadModule log_config_module "/www/modules/mod_log_config.so"
            >
            > So, what's causing the LoadModule lines to be absent from
            > t/conf/httpd.conf when building against the Gentoo non-standard apache? I
            > just don't know enough about the code in Apache-Test directory whereas you
            > will be able to spot this relatively quickly.

            So if in the second case you do:

            perl Makefile.PL ...
            make
            t/TEST -conf

            now add to t/conf/httpd.conf:

            LoadModule log_config_module "/www/modules/mod_log_config.so"

            of course adjusting the path to mod_log_config.so. now running the test suite:

            t/TEST

            does it work all fine? Apache::Test assumes that mod_log_config.so is built in
            and therefore doesn't try to load it, since it's far from trivial to guess
            correctly where that .so lives.

            Apache::Test provides a special functionality which inherits the LoadModule
            settings from your global httpd.conf, and this is why you saw the entry:

            LoadModule log_config_module "/www/modules/mod_log_config.so"

            for your manually built setup. So my guess is that you second setup doesn't
            have a system wide httpd.conf from which Apache::Test can copy the elements from.

            __________________________________________________________________
            Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
            http://stason.org/ mod_perl Guide ---> http://perl.apache.org
            mailto:stas@... http://use.perl.org http://apacheweek.com
            http://modperlbook.org http://apache.org http://ticketmaster.com
          • Haroon Rafique
            On Today at 9:54am, SB= Stas Bekman wrote: SB SB Still, why do you supply CCFLAGS= ${CFLAGS} -fPIC ? Doesn t it work SB without it? Look
            Message 5 of 16 , Apr 24, 2003
              On Today at 9:54am, SB=>Stas Bekman <stas@...> wrote:

              SB>
              SB> Still, why do you supply CCFLAGS="${CFLAGS} -fPIC"? Doesn't it work
              SB> without it? Look at the generated Makefile it already includes -fpic
              SB> (unless you need -fPIC instead).
              SB>

              Hi Stas,

              I will file a bug report with the Gentoo package maintainers regarding the
              CFLAGS issue.

              SB>
              SB> So if in the second case you do:
              SB>
              SB> perl Makefile.PL ...
              SB> make
              SB> t/TEST -conf
              SB>

              I did as you suggested above.

              SB>
              SB> now add to t/conf/httpd.conf:
              SB>
              SB> LoadModule log_config_module "/www/modules/mod_log_config.so"
              SB>
              SB> of course adjusting the path to mod_log_config.so. now running the
              SB> test suite:
              SB>
              SB> t/TEST

              Making good progress here... I followed your instructions and I had to add
              the following 3 lines to t/conf/httpd.conf. After adding them the test
              suite starts to run:

              LoadModule log_config_module "/usr/lib/apache2/mod_log_config.so"
              LoadModule alias_module "/usr/lib/apache2/mod_alias.so"
              LoadModule mime_module "/usr/lib/apache2/mod_mime.so"

              SB>
              SB> Apache::Test provides a special functionality which inherits the
              SB> LoadModule settings from your global httpd.conf, and this is why you
              SB> saw the entry:
              SB>
              SB> LoadModule log_config_module "/www/modules/mod_log_config.so"
              SB>
              SB> for your manually built setup. So my guess is that you second setup
              SB> doesn't have a system wide httpd.conf from which Apache::Test can copy
              SB> the elements from.
              SB>

              Yes, the second apache DOES have a system wide httpd.conf but I don't
              think Apache::Test can find it. It is located in:
              /etc/apache2/conf/apache2.conf

              The file t/conf/apache_test_config.pm looks sort of like a Data::Dumper
              dump of the test configuration parameters. Inside that file, I have cut
              out some lines of interest for you:

              sub new {
              bless( {
              'vars' => {
              'httpd_conf' => '/etc/apache2/conf/httpd.conf',
              },
              'httpd_defines' => {
              'SERVER_CONFIG_FILE' => '/etc/apache2/conf/apache2.conf',
              },
              }, 'ModPerl::TestConfig' );
              }

              So, there are 2 references to system-wide .conf files.
              /etc/apache2/conf/apache2.conf is the correct path and the other path is
              non-existent. Could it be that the code skips adding the lines because it
              deduced the wrong path/filename to inherit the system settings from?

              I did some more detective work and ran:
              t/TEST -conf -httpd_conf /etc/apache2/conf/apache2.conf
              and it did add all the LoadModule lines but with the wrong prefix path,
              e.g.:
              LoadModule access_module "/etc/apache2/modules/mod_access.so"
              The correct path should have been (notice there shouldn't be a modules
              subdirectory):
              "/usr/lib/apache2/mod_access.so"

              Running:
              /usr/sbin/apxs2 -q LIBEXECDIR
              confirms that the prefix should be:
              /usr/lib/apache2

              Running:
              /www/apxs -q LIBEXECDIR
              confirms that the prefix contains the modules directory as shown below:
              /www/modules

              This sort of proves that all of the information is there, but not being
              assembled properly. Anything else I can do to help (besides blaming
              Gentoo's package maintainers)? I am sure once this is fixed several Gentoo
              users will be happy.

              --
              Haroon Rafique
              <haroon.rafique@...>
            • Haroon Rafique
              On Today at 10:42am, HR= Haroon Rafique wrote: HR HR I did some more detective work and ran: HR t/TEST -conf -httpd_conf
              Message 6 of 16 , Apr 24, 2003
                On Today at 10:42am, HR=>Haroon Rafique <haroon.rafique@...> wrote:

                HR>
                HR> I did some more detective work and ran:
                HR> t/TEST -conf -httpd_conf /etc/apache2/conf/apache2.conf
                HR> and it did add all the LoadModule lines but with the wrong prefix path,
                HR> e.g.:
                HR> LoadModule access_module "/etc/apache2/modules/mod_access.so"
                HR> The correct path should have been (notice there shouldn't be a modules
                HR> subdirectory):
                HR> "/usr/lib/apache2/mod_access.so"
                HR>

                Problem sort of solved. Disregard my previous complaint of the wrong
                prefix path. After running:
                t/TEST -conf -httpd_conf /etc/apache2/conf/apache2.conf
                I was complaining that the prefix path was /etc/apache2/modules without
                realizing that there is a symbolic link as follows:

                /etc/apache2/modules -> ../../usr/lib/apache2

                This means that (I feel a little silly for not even trying) that t/TEST
                starts to run after this. So the only outstanding problem now is how to
                have it point to the correct system-wide config file to inherit from?

                Cheers,
                --
                Haroon Rafique
                <haroon.rafique@...>
              • Wes Cravens
                I would like to call a Module::Routine($argument) using variables. I have tried things like eval ${module}::${routine}( info ) ; Which works however eval
                Message 7 of 16 , Apr 24, 2003
                  I would like to call a Module::Routine($argument) using variables.

                  I have tried things like

                  eval "${module}::${routine}('info')";

                  Which works however eval "${module}::${routine}($info)"; will not...

                  I get similar result with anonymous subs such as

                  my $coderef = sub{$module."::".$routine};
                  &$coderef("info");

                  or better examples there of.

                  I am using this so that a control module on my website will read the URI
                  and decide what Module::Routine pair to call. I want this as generic as
                  possible so that third parties can contribute to the site but the core
                  does not need to know they exist.

                  Any advice greatly appreciated.

                  Regards,

                  Wes
                • Richard Clarke
                  Wes, The following has always worked fine for me. $module = Some::Module ; $method = sum_method ; @args = qw/1 2 3/; $module- $method(@args); Richard. ...
                  Message 8 of 16 , Apr 24, 2003
                    Wes,

                    The following has always worked fine for me.

                    $module = "Some::Module";
                    $method = 'sum_method';
                    @args = qw/1 2 3/;
                    $module->$method(@args);

                    Richard.



                    ----- Original Message -----
                    From: "Wes Cravens" <wes@...>
                    To: <modperl@...>
                    Sent: Thursday, April 24, 2003 3:55 PM
                    Subject: Dynamic anonymous subroutines


                    > I would like to call a Module::Routine($argument) using variables.
                    >
                    > I have tried things like
                    >
                    > eval "${module}::${routine}('info')";
                    >
                    > Which works however eval "${module}::${routine}($info)"; will not...
                    >
                    > I get similar result with anonymous subs such as
                    >
                    > my $coderef = sub{$module."::".$routine};
                    > &$coderef("info");
                    >
                    > or better examples there of.
                    >
                    > I am using this so that a control module on my website will read the URI
                    > and decide what Module::Routine pair to call. I want this as generic as
                    > possible so that third parties can contribute to the site but the core
                    > does not need to know they exist.
                    >
                    > Any advice greatly appreciated.
                    >
                    > Regards,
                    >
                    > Wes
                    >
                    >
                    >
                  • Ged Haywood
                    Hi there, ... Try playing around with print STDERR ${module}::${routine}($info) ; etc. and you may see where it s going wrong. Check out also the debugging
                    Message 9 of 16 , Apr 24, 2003
                      Hi there,

                      On Thu, 24 Apr 2003, Wes Cravens wrote:

                      > I would like to call a Module::Routine($argument) using variables.
                      >
                      > I have tried things like
                      >
                      > eval "${module}::${routine}('info')";
                      >
                      > Which works however eval "${module}::${routine}($info)"; will not...

                      Try playing around with

                      print STDERR "${module}::${routine}($info)";

                      etc. and you may see where it's going wrong.

                      Check out also the debugging section of the guide.

                      73,
                      Ged.
                    • Perrin Harkins
                      ... This is already available in a CPAN module called Apache::Dispatch. Check it out and see if meets your needs. - Perrin
                      Message 10 of 16 , Apr 24, 2003
                        Wes Cravens wrote:
                        > I am using this so that a control module on my website will read the URI
                        > and decide what Module::Routine pair to call. I want this as generic as
                        > possible so that third parties can contribute to the site but the core
                        > does not need to know they exist.

                        This is already available in a CPAN module called Apache::Dispatch.
                        Check it out and see if meets your needs.

                        - Perrin
                      • Bernhard van Staveren
                        ... What works for me, if you want to figure out what to do based on the URI that was called on: Assuming that your module is called MyModule, is an object,
                        Message 11 of 16 , Apr 24, 2003
                          On Thu, 24 Apr 2003, Wes Cravens wrote:

                          > I would like to call a Module::Routine($argument) using variables.
                          >
                          > I have tried things like
                          >
                          > eval "${module}::${routine}('info')";
                          >
                          > Which works however eval "${module}::${routine}($info)"; will not...

                          What works for me, if you want to figure out what to do based on the
                          URI that was called on:

                          Assuming that your module is called MyModule, is an object,
                          and has routines named after the first bit of the URI (i.e. /foo/bar) would
                          call your routine as MyModule->foo with 'bar' as only argument - make sure your
                          module has an AUTOLOAD function to deal with unknown routines (uri's) and handle
                          those appropriately:

                          sub handler {
                          my $r=shift;
                          my $module=MyModule->new();
                          my @args=split(/\//, $r->uri());
                          my $cmd=shift(@args);

                          $module->$cmd(@args);
                          }

                          It's not the prettiest way to do it, but it's functional.. at least
                          in my case.

                          --
                          Bernhard van Staveren - madcat(at)ghostfield.com
                          GhostField Internet - http://www.ghostfield.com/
                          "A witty saying proves nothing, but damn it's funny!" - me, 1998
                        • Wes Cravens
                          ... What I really wanted was this $coderef = eval &${module}::${routine} &$coderef{$arg1, $arg2, ...}; Works a treat! Thanks for other input but this is
                          Message 12 of 16 , Apr 24, 2003
                            > > I would like to call a Module::Routine($argument) using variables.
                            > >
                            > > I have tried things like
                            > >
                            > > eval "${module}::${routine}('info')";

                            What I really wanted was this

                            $coderef = eval "\\&${module}::${routine}"

                            &$coderef{$arg1, $arg2, ...};

                            Works a treat!

                            Thanks for other input but this is exactly what is needed. Others
                            mentioned Apache::Dispatch.
                            I can't at the moment recall why but it was disregarded early on in the
                            planning.

                            Cheers,

                            Wes


                            > >
                            > > Which works however eval "${module}::${routine}($info)"; will not...
                            >
                            > What works for me, if you want to figure out what to do based on the
                            > URI that was called on:
                            >
                            > Assuming that your module is called MyModule, is an object,
                            > and has routines named after the first bit of the URI (i.e.
                            > /foo/bar) would
                            > call your routine as MyModule->foo with 'bar' as only
                            > argument - make sure your
                            > module has an AUTOLOAD function to deal with unknown routines
                            > (uri's) and handle
                            > those appropriately:
                            >
                            > sub handler {
                            > my $r=shift;
                            > my $module=MyModule->new();
                            > my @args=split(/\//, $r->uri());
                            > my $cmd=shift(@args);
                            >
                            > $module->$cmd(@args);
                            > }
                            >
                            > It's not the prettiest way to do it, but it's functional.. at least
                            > in my case.
                            >
                            > --
                            > Bernhard van Staveren - madcat(at)ghostfield.com
                            > GhostField Internet - http://www.ghostfield.com/
                            > "A witty saying proves nothing, but damn it's funny!" - me, 1998
                          • Haroon Rafique
                            On Yesterday at 10:48am, HR= Haroon Rafique wrote: HR So the only outstanding problem now is how to have it point to the HR
                            Message 13 of 16 , Apr 25, 2003
                              On Yesterday at 10:48am, HR=>Haroon Rafique <haroon.rafique@...> wrote:

                              HR> So the only outstanding problem now is how to have it point to the
                              HR> correct system-wide config file to inherit from?
                              HR>

                              The following patch fixes the problem:

                              Index: ./Apache-Test/lib/Apache/TestConfigParse.pm
                              ===================================================================
                              RCS file: /home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm,v
                              retrieving revision 1.32
                              diff -u -r1.32 TestConfigParse.pm
                              --- ./Apache-Test/lib/Apache/TestConfigParse.pm 23 Apr 2003 02:24:16 -0000 1.32
                              +++ ./Apache-Test/lib/Apache/TestConfigParse.pm 25 Apr 2003 16:03:20 -0000
                              @@ -225,6 +225,12 @@
                              my $default_conf = $self->{httpd_defines}->{SERVER_CONFIG_FILE};
                              $default_conf ||= catfile qw(conf httpd.conf);
                              $file = catfile $base, $default_conf;
                              + unless (-e $file) {
                              + # SERVER_CONFIG_FILE might be an absolute path,
                              + # e.g., in the case of Gentoo Linux
                              + # SERVER_CONFIG_FILE="/etc/apache2/conf/apache2.conf"
                              + $file = $self->{httpd_defines}->{SERVER_CONFIG_FILE};
                              + }
                              }
                              }


                              As stated in one of the commented out lines in the patch, the
                              SERVER_CONFIG_FILE directive in Gentoo's case happens to be an absolute
                              path so we must use it as it is.

                              Now, onto making the tests run under portage (Gentoo's package management
                              system).
                              --
                              Haroon Rafique
                              <haroon.rafique@...>
                            • Stas Bekman
                              ... Thanks a lot for this debug and patching. Can you please verify that this patch still works for you? It s essentially the same, but also tests whether the
                              Message 14 of 16 , Apr 26, 2003
                                Haroon Rafique wrote:
                                > On Yesterday at 10:48am, HR=>Haroon Rafique <haroon.rafique@...> wrote:
                                >
                                > HR> So the only outstanding problem now is how to have it point to the
                                > HR> correct system-wide config file to inherit from?
                                > HR>
                                >
                                > The following patch fixes the problem:
                                >
                                > Index: ./Apache-Test/lib/Apache/TestConfigParse.pm
                                > ===================================================================
                                > RCS file: /home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm,v
                                > retrieving revision 1.32
                                > diff -u -r1.32 TestConfigParse.pm
                                > --- ./Apache-Test/lib/Apache/TestConfigParse.pm 23 Apr 2003 02:24:16 -0000 1.32
                                > +++ ./Apache-Test/lib/Apache/TestConfigParse.pm 25 Apr 2003 16:03:20 -0000
                                > @@ -225,6 +225,12 @@
                                > my $default_conf = $self->{httpd_defines}->{SERVER_CONFIG_FILE};
                                > $default_conf ||= catfile qw(conf httpd.conf);
                                > $file = catfile $base, $default_conf;
                                > + unless (-e $file) {
                                > + # SERVER_CONFIG_FILE might be an absolute path,
                                > + # e.g., in the case of Gentoo Linux
                                > + # SERVER_CONFIG_FILE="/etc/apache2/conf/apache2.conf"
                                > + $file = $self->{httpd_defines}->{SERVER_CONFIG_FILE};
                                > + }
                                > }
                                > }
                                >
                                >
                                > As stated in one of the commented out lines in the patch, the
                                > SERVER_CONFIG_FILE directive in Gentoo's case happens to be an absolute
                                > path so we must use it as it is.

                                Thanks a lot for this debug and patching. Can you please verify that this
                                patch still works for you? It's essentially the same, but also tests whether
                                the default conf file exists.

                                Index: Apache-Test/lib/Apache/TestConfigParse.pm
                                ===================================================================
                                RCS file:
                                /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm,v
                                retrieving revision 1.32
                                diff -u -r1.32 TestConfigParse.pm
                                --- Apache-Test/lib/Apache/TestConfigParse.pm 23 Apr 2003 02:24:16 -0000
                                1.32
                                +++ Apache-Test/lib/Apache/TestConfigParse.pm 27 Apr 2003 04:37:01 -0000
                                @@ -225,6 +225,8 @@
                                my $default_conf = $self->{httpd_defines}->{SERVER_CONFIG_FILE};
                                $default_conf ||= catfile qw(conf httpd.conf);
                                $file = catfile $base, $default_conf;
                                + # SERVER_CONFIG_FILE might be an absolute path
                                + $file = $default_conf if !-e $file and -e $default_conf;
                                }
                                }



                                __________________________________________________________________
                                Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                                http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                                mailto:stas@... http://use.perl.org http://apacheweek.com
                                http://modperlbook.org http://apache.org http://ticketmaster.com
                              • Haroon Rafique
                                On Today at 2:40pm, SB= Stas Bekman wrote: SB SB Thanks a lot for this debug and patching. Can you please verify that this SB patch still
                                Message 15 of 16 , Apr 27, 2003
                                  On Today at 2:40pm, SB=>Stas Bekman <stas@...> wrote:

                                  SB>
                                  SB> Thanks a lot for this debug and patching. Can you please verify that this
                                  SB> patch still works for you? It's essentially the same, but also tests whether
                                  SB> the default conf file exists.
                                  SB>

                                  You're welcome. And thanks for the minimalist and more clear patch.
                                  It works perfectly. I have other issues to sort out which are almost
                                  certainly not mod_perl related and most certainly Gentoo-related. I will
                                  keep you updated if I need further help.

                                  SB> Index: Apache-Test/lib/Apache/TestConfigParse.pm
                                  SB> ===================================================================
                                  SB> RCS file:
                                  SB> /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfigParse.pm,v
                                  SB> retrieving revision 1.32
                                  SB> diff -u -r1.32 TestConfigParse.pm
                                  SB> --- Apache-Test/lib/Apache/TestConfigParse.pm 23 Apr 2003 02:24:16 -0000
                                  SB> 1.32
                                  SB> +++ Apache-Test/lib/Apache/TestConfigParse.pm 27 Apr 2003 04:37:01 -0000
                                  SB> @@ -225,6 +225,8 @@
                                  SB> my $default_conf = $self->{httpd_defines}->{SERVER_CONFIG_FILE};
                                  SB> $default_conf ||= catfile qw(conf httpd.conf);
                                  SB> $file = catfile $base, $default_conf;
                                  SB> + # SERVER_CONFIG_FILE might be an absolute path
                                  SB> + $file = $default_conf if !-e $file and -e $default_conf;
                                  SB> }
                                  SB> }
                                  SB>

                                  Regards,
                                  --
                                  Haroon Rafique
                                  <haroon.rafique@...>
                                • Stas Bekman
                                  ... Thanks Haroon, it s now committed. ... No problem. __________________________________________________________________ Stas Bekman JAm_pH ------
                                  Message 16 of 16 , Apr 27, 2003
                                    Haroon Rafique wrote:
                                    > On Today at 2:40pm, SB=>Stas Bekman <stas@...> wrote:
                                    >
                                    > SB>
                                    > SB> Thanks a lot for this debug and patching. Can you please verify that this
                                    > SB> patch still works for you? It's essentially the same, but also tests whether
                                    > SB> the default conf file exists.
                                    > SB>
                                    >
                                    > You're welcome. And thanks for the minimalist and more clear patch.
                                    > It works perfectly.

                                    Thanks Haroon, it's now committed.

                                    > I have other issues to sort out which are almost
                                    > certainly not mod_perl related and most certainly Gentoo-related. I will
                                    > keep you updated if I need further help.

                                    No problem.

                                    __________________________________________________________________
                                    Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
                                    http://stason.org/ mod_perl Guide ---> http://perl.apache.org
                                    mailto:stas@... http://use.perl.org http://apacheweek.com
                                    http://modperlbook.org http://apache.org http://ticketmaster.com
                                  Your message has been successfully submitted and would be delivered to recipients shortly.