Mailing List Archive

On 10/14/07, Marvin Humphrey <marvin@rectangular.com> wrote:
> > My first check in will be probably a couple of tiny changes to the
> > Builder stuff that made my life easier: reading symlinks and ignoring
> > emacs temp files.
>
> OK, I have no idea what you have in mind as far as symlinks but I'll
> just review the commit. :) As far as ignoring emacs temp files, I
> imagine you're talking adding their extension to MANIFEST.SKIP?
> Sounds good.

The symlinks change is just a configuration change within
Module::Build and Boilerplater to allow symlinked directories to be
followed. I was using this to have KSx extensions with both the C and
Perl code in the same tree. This is a slightly hackish solution, but
changing the configuration to allow them to be intermixed for real
seemed hard.

Ignoring the emacs temp files is also mostly a configuration change,
although it requires a little more ugliness. Emacs lock files have
the format .#filename where the ending (.c or .h) is unchanged. This
causes strange errors if one runs Build while emacs has unsaved files.

I apologize that these aren't great first commits, but I've been
making them by hand in all the trees I've checked out so it seemed
like a good idea. Feel free to revert as necessary.

Nathan Kurz
nate@verse.com

_______________________________________________
KinoSearch mailing list
KinoSearch@rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch

On Oct 15, 2007, at 7:20 PM, Nathan Kurz wrote:

> The symlinks change is just a configuration change within
> Module::Build and Boilerplater to allow symlinked directories to be
> followed. I was using this to have KSx extensions with both the C and
> Perl code in the same tree.

Ah.

> Ignoring the emacs temp files is also mostly a configuration change,
> although it requires a little more ugliness. Emacs lock files have
> the format .#filename where the ending (.c or .h) is unchanged. This
> causes strange errors if one runs Build while emacs has unsaved files.

Yeah, I can see that. Another gimme.

I didn't get the rscan_dir thing, though. That's part of the
Module::Build public API, we don't have to copy it... but I don't
even see where you're using it.

Actually, I can see some uses for it. It looks like we can kill off
the _find_files sub and swap in calls to rscan_dir!

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/



_______________________________________________
KinoSearch mailing list
KinoSearch@rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch

On 10/16/07, Marvin Humphrey <marvin@rectangular.com> wrote:
> I didn't get the rscan_dir thing, though. That's part of the
> Module::Build public API, we don't have to copy it... but I don't
> even see where you're using it.

It gets called internally. We don't have to copy it, but we do have
to override it. But I couldn't figure out any way to do what I wanted
via a call to SUPER, hence the ugly cut and paste.

Nathan Kurz
nate@verse.com

_______________________________________________
KinoSearch mailing list
KinoSearch@rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch

On Oct 16, 2007, at 8:29 AM, Nathan Kurz wrote:

> On 10/16/07, Marvin Humphrey <marvin@rectangular.com> wrote:
>> I didn't get the rscan_dir thing, though. That's part of the
>> Module::Build public API, we don't have to copy it... but I don't
>> even see where you're using it.
>
> It gets called internally. We don't have to copy it, but we do have
> to override it. But I couldn't figure out any way to do what I wanted
> via a call to SUPER, hence the ugly cut and paste.

... Because of the symlink thing. Gotcha. Looks good.

I went and zapped _find_files, replacing all calls with rscan_dir.

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/



_______________________________________________
KinoSearch mailing list
KinoSearch@rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch