On Sep 16, 2008, at 12:02, Eric Wilhelm wrote:
Because you want to capture the output of a command or because you
want
to have quoting bugs?
The former.
What do you plan to replace these things with?
If I knew that to a sufficient level of detail to make it clear, I
would
have code. Perhaps you would like to meet up and help with the
design?
Not really. I don't really care about this stuff, as long as it works.
And so far, for my uses, what's there has worked.
I've been thinking that the Compat needs its own UNIX/Windows/etc
classes - or maybe just tables of methods which are installed in the
Compat object at compile-time. But basically some of it goes in
Compat.
Um, isn't Compat just for generating a Makefile.PL?
Other parts could maybe be made into Module::Build->sys->something(),
such that there is a more compact object which could be more easily
tested and decoupled where necessary, etc. Implicit in this is the
idea of collecting the setup and knowledge of the system and making it
be distinct from the builder.
Sure.
I guess the guiding concept would be "does an author need to override
this method to create their custom build class?" - if that answer
is "no", then the method really belongs in a utility or some other
small piece which M::B then 'hasa's.
The other question, of course, is has an author used an existing
method in a subclass or Build.PL. If the answer is "yes", you'll need
to provide some backwards compatibility for those authors, at least
for documented methods.
Still only a sketch. I suspect that whatever we come up with will
also
inform the plugins scheme.
Really? I thought that you were basically just talking about a utility
for manipulating file names and providing access to the system.
But first, there's still this t/xs.t failure.
Right. No takers on that, yet?
Best,
David
