[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?
- [Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1-cleanup, penguindude24, 2014/09/10
- [Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1-cleanup, socketpro, 2014/09/13
- Re: [Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1-cleanup, socketpro, 2014/09/14
- [Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1-cleanup,
socketpro <=
- [Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1-cleanup, socketpro, 2014/09/15
- Re: [Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1-cleanup, socketpro, 2014/09/15
- Re: [Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1-cleanup, socketpro, 2014/09/15
- Re: [Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1-cleanup, socketpro, 2014/09/15
- Re: [Savannah-hackers-public] Porting savane from PHP to Perl on version 3.1-cleanup, socketpro, 2014/09/15