[Koha-patches] [PATCH] Replace TMPL_ELSIF with TMPL_ELSE and TMPL_IF in label-manager.tmpl;

[Joe Atzberger]

On Tue, Aug 26, 2008 at 7:00 PM, MJ Ray <mjr at phonecoop.coop> wrote:

> Mason James <mason.loves.sushi at gmail.com> wrote:
> > On 2008/07/29, at 11:37 PM, MJ Ray wrote:
> > > Consider this the first, then!
> > > http://rt.cpan.org/Ticket/Display.html?id=38013
> > [...]
> > I've just built HTML-Template-Pro-0.70 fine on my OSX 10.4 box, 1st
> > go even.
> > MJR, This may well be an issue with your specific system alone?,
>
> I don't see why.  The then-current H:T:P built fine for me too on the
> same system under 10.4, but fails under 10.5.  The maintainer hasn't
> yet suggested that it's a local configuration error and it's hard to
> see how it could be - I've changed very few settings.  It might be a
> problem with fink or perl on 10.5, but I probably won't be the only
> user of those versions.



See the *Known Problems* section of the
perlmacos<http://perldoc.perl.org/5.8.8/perlmacosx.html>perldoc:

If you have installed extra libraries such as GDBM through Fink (in other
words, you have libraries under */sw/lib*), or libdlcompat to *
/usr/local/lib*, you may need to be extra careful when running Configure to
not to confuse Configure and Perl about which libraries to use.

Sounds like a likely vector.


> > I think we do need to properly prove that H:T:P's ELSIF's are buggy
> > before we remove them,
> > as they make the template logic a lot saner
>
> IF ... ELSIF ... /IF isn't much saner than IF ... ELSE IF ... /IF /IF


It is saner.  And as you increase the depth, it is exceedingly saner.

<!-- TMPL_IF NAME="var1" -->
<!-- TMPL_ELSE -->
     <!-- TMPL_IF NAME="var2" -->
     <!-- TMPL_ELSE -->
         <!-- TMPL_IF NAME="var3" -->
         <!-- TMPL_ELSE -->
             <!-- TMPL_IF NAME="var4" -->
             <!-- /TMPL_IF -->
         <!-- /TMPL_IF -->
     <!-- /TMPL_IF -->
<!-- /TMPL_IF -->

vs.

<!-- TMPL_IF NAME="var1" -->
<!-- TMPL_ELSIF NAME="var2" -->
<!-- TMPL_ELSIF NAME="var3" -->
<!-- TMPL_ELSIF NAME="var4" -->
<!-- /TMPL_IF -->

There is no reason to be persuaded that the former is "just as good" or
"almost as good" or otherwise worth abandoning.  Espcially when it has
nothing to do with your problem, the bit-depth your module was compiled
with.  It is not H:T:P's job to override your perl config.


> [...]
> > And I'm pretty sure that with some help and persistent we can sort
> > out MJR's OSX H:T:P build issue.
>
> I'm pretty sure it will be solved eventually, but it's still upsetting
> that a koha.org-requested H:T:P feature screwed one of our early
> adopters and other developers were so "works for us, so let's use that
> feature more and more without waiting for it to work for everyone"
> about it.
>

You're on a OS that's only months old, with a perl that isn't configured
optimally for your architecture, and as a result your module is compiled
incorrectly.  There is no protection against this level of administrative
error.  You can feel as abandoned as you want to, but none of this is Koha's
problem.  In reality you have had very responsive and detailed interaction
with many of us on this issue, all of it coming down to debugging your local
config.

And yet you act like the Koha community should do your job for you, or wait
until you can figure it out.  Yeah.  Good luck with that.

--joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-patches/attachments/20080826/e097af25/attachment-0002.htm>