Question: Inline::C module packaging?

[Lee]

Is there a preferred method of packaging an Inline::C module, perhaps
one that would compile the C in the correct place during the
installation, rather than on first run?

Thanks in anticipation
Lee

 

[Ben Morrow]

Is there a preferred method of packaging an Inline::C module, perhaps
one that would compile the C in the correct place during the
installation, rather than on first run?

Read the docs for Inline.

Ben

 

[Lee]

Read the docs for Inline.

Me too, but it says:

Finally, you need to modify the Makefile.PL. Simply change:
use ExtUtils::MakeMaker;
to
use Inline::MakeMaker;

Won't that upset machines and users that don't have Inline installed?

Neither did the Iline docs help me solve errors along the lines of "No
rule to make target ... needed by `pure_all'," for which I copied
something from
http://search.cpan.org/src/FXN/Algorithm-Combinatorics-0.10/Makefile.PL.

And then there's the whole business of supplying NAME/VERSION and
having to disable one to run make test, which is not something I would
like to pass on to my end-users.

I don't always find the "RTFM" response helpful, or even worth typing.

lee

 

[Ben Morrow]

Me too, but it says:

Finally, you need to modify the Makefile.PL. Simply change:
use ExtUtils::MakeMaker;
to
use Inline::MakeMaker;

Won't that upset machines and users that don't have Inline installed?

Yes. Maybe... You can package Inline::MakeMaker with your dist, and put
a use lib line in your Makefile.PL to find it. Or you could use
Module::Install, which claims to handle Inline stuff; I've never used
it, though.

Neither did the Iline docs help me solve errors along the lines of "No
rule to make target ... needed by `pure_all'," for which I copied
something from
http://search.cpan.org/src/FXN/Algorithm-Combinatorics-0.10/Makefile.PL.

Ah yes, I remember... This was one of the main reasons I gave up on
Inline::C and just learned XS. It's really not that hard, once you've
got enough of a grasp of perl internals to write anything useful. The
other Inline:: modules, OTOH, I could see could be useful.

And then there's the whole business of supplying NAME/VERSION and
having to disable one to run make test, which is not something I would
like to pass on to my end-users.

My recommendation would be to file a bug or bugs with the maintainers of
Inline. The fact that these issues still haven't been fixed since I last
used it about two years ago suggest they don't take these things
seriously enough, though...

I don't always find the "RTFM" response helpful, or even worth typing.

....which is why you should have written something more along the lines
of 'I have read the Inline docs, but the suggestion to <foo> fails for
me because...'. Then you have a much better chance of getting the help
you need without wasting time.

Ben

 

[Anno Siegel]

Me too, but it says:

You say you have read the doc but you must have missed the second
paragraph that says:

Code
that is Inlined into distributed modules (like on the CPAN) will get
compiled when the module is installed, ...

Finally, you need to modify the Makefile.PL. Simply change:
use ExtUtils::MakeMaker;
to
use Inline::MakeMaker;

Won't that upset machines and users that don't have Inline installed?

Yes, you have a module dependency. Nothing unusual. What did you
expect?

Neither did the Iline docs help me solve errors along the lines of "No
rule to make target ... needed by `pure_all'," for which I copied
something from
http://search.cpan.org/src/FXN/Algorithm-Combinatorics-0.10/Makefile.PL.

You didn't ask about that. How should replies answer questions you
haven't asked?

And then there's the whole business of supplying NAME/VERSION and
having to disable one to run make test, which is not something I would
like to pass on to my end-users.

I'm not sure what you mean here, but you didn't ask about that either.

I don't always find the "RTFM" response helpful, or even worth typing.

Then don't give the impression that you haven't even looked at it.

Anno

 

[xhoster]

Me too, but it says:

Finally, you need to modify the Makefile.PL. Simply change:
use ExtUtils::MakeMaker;
to
use Inline::MakeMaker;

Won't that upset machines and users that don't have Inline installed?

Neither did the Iline docs help me solve errors along the lines of "No
rule to make target ... needed by `pure_all'," for which I copied
something from
http://search.cpan.org/src/FXN/Algorithm-Combinatorics-0.10/Makefile.PL.

And then there's the whole business of supplying NAME/VERSION and
having to disable one to run make test, which is not something I would
like to pass on to my end-users.

So why didn't you mention all this stuff in your original post? If you
did, we wouldn't have to shame it out of you but suggesting that maybe you
should read the manual.

I don't always find the "RTFM" response helpful, or even worth typing.

Then ask smart questions right up front.

Xho

 

[Sisyphus]

My recommendation would be to file a bug or bugs with the maintainers of
Inline.

Good advice. Add it to the list at
http://rt.cpan.org/Public/Dist/Display.html?Name=Inline (if it's not already
there) . Probably worthwhile raising it on the Inline mailing list, too.

The fact that these issues still haven't been fixed since I last
used it about two years ago suggest they don't take these things
seriously enough, though...

The problem is that the owner (Ingy) is usually pre-occupied with other
stuff. A few months ago he made some noises about releasing Inline-0.45 ....
but that was a few months ago ....

Eric Wilhelm has made available a patched version of Inline-0.44 at
http://scratchcomputing.com/code/x-Inline/Inline-0.44_01.tar.gz - but I
don't know precisely which issues it addresses.

Cheers,
Rob

 

[Sisyphus]

Is there a preferred method of packaging an Inline::C module, perhaps
one that would compile the C in the correct place during the
installation, rather than on first run?

My preference is to package it as a normal (cpan-type distro) source
package.

If you run your Inline::C script with the Config option
'CLEAN_AFTER_BUILD=>0', you'll be able to go into the _Inline/build
directory and grab the XS file that it created.

Change the 'MODULE' and 'PACKAGE' entries in that XS file as appropriate,
then bundle the XS file with the other usual files (the normal '.pm',
Makefile.PL, CHANGES, README, MANIFEST, test suite) and you've got a distro
that can be built in the usual way without any dependence upon Inline at
all.

As an alternative, I've put Inline::C2XS on CPAN - which will write the XS
file for you from your Inline::C code. That module should really be doing
its stuff by plugging into the Inline::C module functionality .... but it
doesn't do it that way. Instead it's a (rather poor) wheel-reinvention that
just happens to work for me - and may also work for you if you choose to use
it.

Cheers,
Rob

 

[Anno Siegel]

[...]

I don't always find the "RTFM" response helpful, or even worth typing.

Then ask smart questions right up front.

That probably got you a private reply to the effect that it wasn't
helpful but please don't consider him/her rude.

Anno

 

[Lee]

So why didn't you mention all this stuff in your original post? If you
did, we wouldn't have to shame it out of you but suggesting that maybe you
should read the manual.

Since the manual did not answer the question, I still think RTFM was
the wrong response, as it usually is. But that's usenet, I suppose.