savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1


From: socketpro
Subject: [Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1-cleanup
Date: Mon, 15 Sep 2014 02:21:10 -0400

I did `git clone' from the "administration" project, not the savane-* stuff. I 
just said savane because it's easier to refer to.

As for incorporating additions, I thought it is best to move the lib/ directory 
to be its own package. I moved the lib/ directory to ../Savane-Util, and I 
intended that it is to be an independent Perl distribution, i.e, 
Savane-Util-3.1.tar.gz. I could not name it Savane, because that is the 
$(PACKAGE_NAME) of savane. Savane-Util conveys the purpose of the module, 
besides ExtUtils::MakeMaker requires that the name actually be in the module. 
File lib/Savane/Util.pm must exist because I did "NAME => 'Savane::Util'" in 
Makefile.PL.

I think that it is bad practice to nest a Perl distribution under Autotools 
like that. If it was one .pm file, then okay, but it is many of them. So I 
think this is best managed by Perl's own infrastructure, such as Module::Build 
or ExtUtils::MakeMaker. It's scary having two build systems interact like that. 
For instance, I had a Perl package nested in this other package I worked on, 
and one of the problems to surface was an "infinite make all." And some times 
things would break (builld wise) and it took me too darn long to zoom in on the 
issue.

It took so many hours to debug and trying to make Perl play nice with Autotools 
on that old project I had. Too much "new methodology" was being used and 
developed for some routine stuff. I just gave up and now it's a Foo*tar.gz.

The bad thing here is that git has trouble moving things (file and project 
history) from project to project. It's possible--just extremely cumbersome. The 
quickest solution takes about a dozen or so git commands. With subversion, all 
I would have to do with subversion is a `svn mv SERVER/OLD_PATH  
SERVER/NEW_PATH, but git cannot do that... but whatever.

I can leave the Savane::* modules under lib/. In that case, I will have to 
re-test the build system to make sure it works. In my mind I was bent on moving 
lib/Savane/* to being it's own Perl distribution.

I like following best practices because in the end it saves work, reduces debug 
time, prevents errors, saves time, things are uniform and can be recognized by 
other developers instantly, it's basically proper form, and it's how a "real 
pro" would have it done.

I plan to run those dozen git commands when I wake up tomorrow.

What do you think about the lib/Savane.pm issue?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]