Make 
Author Message
 Make

I have a perl script that makes changes to sendmail's access file
(just a plain text file). After any changes are made, the command
"make access.db" needs to be issued at the prompt to re-compile the
hash database.. I need my perl program to do that itself.

I've tried the Make module from CPAN but it does not work with this
Makefile for some reason (even though it's just the standard sendmail
Makefile). At the end of this message I'll paste the actual contents
of the Makefile, in case it matters.

Does anyone else know how I can get the hash db to be recompiled since
the Make module doesn't work? I contacted the author of the module and
he looked at the Makefile but was unable to figure out why his module
wouldn't process it.

First, here's my code trying to use the Make module (which the author
looked at and OKed):

##########################################
chdir ("/etc/mail");
my $make = Make->new();
$make->Make("./access.db");
##########################################

The error I get (which the author can't figure out) when I try to
execute the above code is:

Cannot `Make' - no target ./access.db at
/usr/lib/perl5/site_perl/5.005/Make.pm
line 1164.

Here is the contents of the Makefile. Again, its just the standard
sendmail Makefile found in /etc/mail/

##########################################
all: virtusertable.db access.db domaintable.db mailertable.db

%.db : %

clean:

##########################################

Any ideas? Many thanks! Fortunately this is the last big hurdle to get
my little temporary-auto-rejection anti-spam script working. :)

Thanks!!

Jeremy



Tue, 11 Feb 2003 03:00:00 GMT  
 Make

Quote:
>...
>Does anyone else know how I can get the hash db to be recompiled since
>the Make module doesn't work? I contacted the author of the module and
>he looked at the Makefile but was unable to figure out why his module
>wouldn't process it.

>First, here's my code trying to use the Make module (which the author
>looked at and OKed):

>##########################################
>chdir ("/etc/mail");
>my $make = Make->new();
>$make->Make("./access.db");
>##########################################

Please excuse the haste of my last post.  I looked at the Make.pm file a
second time and noticed that the module does NOT fork/exec the make
utility.  I apologize.

The problem you're encountering is that the module keeps track of
dependencies in a hash and the target name is used as a
key.  Unfortunately, the check for the existence of the target doesn't
strip off a leading `./' before looking it up in the hash.  Here's a test I
ran.  First, here's the Makefile I'm using:

         [ifr] /home/garry/.cpan/build/Make-1.00/t $ cat Makefile
         target:

         [ifr] /home/garry/.cpan/build/Make-1.00/t $

Here's what happens when I run the Solaris make utility:

         [ifr] /home/garry/.cpan/build/Make-1.00/t $ make target
         making target
         [ifr] /home/garry/.cpan/build/Make-1.00/t $ make ./target
         making target
         [ifr] /home/garry/.cpan/build/Make-1.00/t $

So the real make utility doesn't mind if you prefix the target with a `./'
for a "current directory" target.  (I also checked this with GNU make on
another machine and got the same results -- GNU make doesn't mind the `./'
either.)

But the Make::Make() method isn't as forgiving:

         [ifr] /home/garry/.cpan/build/Make-1.00/t $ PERL5LIB=.. perl
-MMake -we '$m=Make->new;$m->Make("./target");'
         Reading ../Make.pm
         Reading /home/garry/.cpan/build/Make-1.00/t/Makefile
         Make ./target
         Cannot `Make' - no target ./target at ../Make.pm line 1164.
         [ifr] /home/garry/.cpan/build/Make-1.00/t $

This duplicates the results you're getting.  Modifying the argument to the
Make() method to NOT include the leading `./' on the target name fixes the
problem:

         [ifr] /home/garry/.cpan/build/Make-1.00/t $ PERL5LIB=.. perl
-MMake -we '$m=Make->new;$m->Make("target");'
         Reading ../Make.pm
         Reading /home/garry/.cpan/build/Make-1.00/t/Makefile
         making target
         [ifr] /home/garry/.cpan/build/Make-1.00/t $

The Make::Make() method is insisting on an exact match of a target name for
a target in the current directory.

If you want the same behavior out of Make::Make(), you will have to modify
the Make.pm module to be more forgiving for a current directory
target.  (The change should probably be placed in the Make::apply()
subroutine at line 1132 or in the Make::Make() subroutine at line
1182.)  Of course, you could just change the target name to NOT include the
leading `./' for current directory targets.

Hope this helps (as opposed to my last post, that is).

-Garry Williams



Wed, 12 Feb 2003 03:00:00 GMT  
 Make

Quote:
>Does anyone else know how I can get the hash db to be recompiled since
>the Make module doesn't work?

Try this instead:

         chdir ('/etc/mail') || die "chdir: $!\n";
         system('make', 'access.db') && die "make failed: $?\n";

It appears that the Make module does a fork/exec of the make utility anyway.

-Garry Williams



Wed, 12 Feb 2003 03:00:00 GMT  
 Make

Quote:

> Does anyone else know how I can get the hash db to be recompiled since
> the Make module doesn't work? I contacted the author of the module and
> he looked at the Makefile but was unable to figure out why his module
> wouldn't process it.
> $make->Make("./access.db");

Try passing "access.db" to Make rather than "./access.db", since
you really don't have a target called that.

Or, consider not using the makefile at all; mimic the behaviour
of the makefile but calling makemap yourself:

Quote:
> %.db : %


system "makemap hash access.db < access" and die "system failed: $?";

Quote:
> Any ideas? Many thanks! Fortunately this is the last big hurdle to get
> my little temporary-auto-rejection anti-spam script working. :)

So even hardcoding stuff into your script is justifyiable :-)

--
believing is seeing

http://www.forum2.org/gaal/



Thu, 13 Feb 2003 06:23:10 GMT  
 Make

Quote:

> The problem you're encountering is that the module keeps track of
> dependencies in a hash and the target name is used as a key.
> Unfortunately, the check for the existence of the target doesn't
> strip off a leading `./' before looking it up in the hash.

Note that Jeremy uses wildcards in his Makefile.  Maybe the problem is
with those wildcards?

I figure, if the Makefile has this:

%.out: %
        frobnicate $<

Then it ought to happily work for "make foo.out" and "make
../strange/foo.out" and "make ./foo.out".  Or even "make /.out".

No?  Does make do something smarter than just plugging in the strings
passed as targets?

kai
--
I like BOTH kinds of music.



Thu, 13 Feb 2003 03:00:00 GMT  
 Make

Quote:

> > The problem you're encountering is that the module keeps track of
> > dependencies in a hash and the target name is used as a key.
> > Unfortunately, the check for the existence of the target doesn't
> > strip off a leading `./' before looking it up in the hash.

>Note that Jeremy uses wildcards in his Makefile.  Maybe the problem is
>with those wildcards?

>I figure, if the Makefile has this:

>%.out: %
>         frobnicate $<

>Then it ought to happily work for "make foo.out" and "make
>../strange/foo.out" and "make ./foo.out".  Or even "make /.out".

>No?  Does make do something smarter than just plugging in the strings
>passed as targets?

Yes.

Here's an excerpt from the Solaris manual page for the make utility:

      target [+ target...] :
             Target group. The rule in the target entry builds all
            the indicated targets as a group.  It is normally per-
            formed only once per make run, but is checked for com-
            mand  dependencies every time a target in the group is
            encountered in the dependency scan.

      %     Pattern matching wild card  metacharacter.   Like  the
            `*' shell wild card, `%' matches any string of zero or
            more characters in a target name or dependency, in the
            target  portion  of a conditional macro definition, or
            within a pattern replacement  macro  reference.   Note
            that  only one `%' can appear in a target, dependency-
            name, or pattern-replacement macro reference.

      ./pathname
            make ignores the leading `./' characters from  targets
            with  names  given as pathnames relative to "dot," the
            working directory.

The behavior that Jeremy expects is defined explicitly by the make
utility.  (I presume that GNU make defines this behavior too, since it
actually produces the same results in my tests.  But I didn't have a copy
of the info file for make to verify it.)  The problem he encountered is the
CPAN Make module's implementation of a different behavior.  That module is
implemented to *not* ignore leading `./' characters from targets "given as
relative to" the "working directory".

The wild card in the make target doesn't change that.

I suggested that Jeremy just change the target to not include the `./'
characters.  Gaal Yahas made the same suggestion and went further to point
out that skipping the "make" altogether would be okay, since it is simple
to just invoke the makemap program directly to create a new version of the
access.db file.  Either approach will get around the problem.

But I guess I'm getting off the list's chartered topic...

-Garry Williams



Thu, 13 Feb 2003 03:00:00 GMT  
 Make
Fyi, I got the exact same results when trying to

$make->Make("access.db");
$make->Make("./access.db");
$make->Make("/etc/mail/access.db");

but

system "makemap hash access.db < access";

worked like a charm.

Thanks everyone!

On Sat, 26 Aug 2000 14:15:51 -0400, "Garry T. Williams"

Quote:

>>Does anyone else know how I can get the hash db to be recompiled since
>>the Make module doesn't work? I contacted the author of the module and
>>he looked at the Makefile but was unable to figure out why his module
>>wouldn't process it.
...
>The problem you're encountering is that the module keeps track of
>dependencies in a hash and the target name is used as a
>key.  Unfortunately, the check for the existence of the target doesn't
>strip off a leading `./' before looking it up in the hash.  Here's a test I
>ran.  First, here's the Makefile I'm using:
...
>If you want the same behavior out of Make::Make(), you will have to modify
>the Make.pm module to be more forgiving for a current directory
>target.  (The change should probably be placed in the Make::apply()
>subroutine at line 1132 or in the Make::Make() subroutine at line
>1182.)  Of course, you could just change the target name to NOT include the
>leading `./' for current directory targets.



Fri, 14 Feb 2003 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Just a test for new account. sorry

2. Blind Vigilantes

3. Dataline Releases Rapid e-Business Development System: net.db 2.0

4. Dynamic Query

5. This post suggests that IPX/SPX protocol on NT may be the culprit ...

6. Tomorrow

7. DB2 Connectivity with Delphi 2 C/S

8. learning Delphi...

9. How do I check if Button2 is pressed when doing things in Button1?

10. Use of Autoincrement fields in Paradox

11. Cannot Initialize IDAPI ---when DB unit is not include in program

12. Multi users with paradox

 

 
Powered by phpBB® Forum Software