Both are wrong ;)

When building a module, you're not building perl (like perlembed), so use a Makefile.PL

See perlxstut, h2xs, module-starter, ExtUtils::MakeMaker/Module::Build

Any thoughts? Could it be done better or differently?

If you insist invoking gcc yourself, don't assume everyone hash bash, just write a perl program to invoke gcc

system 'gcc', $ccflags, $in, $out ...;
[download]

... use a Makefile.PL ...

This is really the best option, and it's not hard once you figure out which of ExtUtils::MakeMaker's many options to tweak:

use ExtUtils::MakeMaker;
WriteMakefile(
        NAME    => 'YourModule',
        OBJECT  => 'YourModule_wrap.o',
        # Add extra include paths here, if needed
#        INC     => '-I/path/to/include',
        # Add shared and static libraries here, if needed
#        LDFROM  => 'YourModule_wrap.o -L/path/to/lib -lyourmodule',
);
[download]

Basically, you add Foo_wrap.o to OBJECT, and possibly modify INC and LDFROM if you're compiling against a C library. SWIG could/should even generate a basic Makefile.PL when it generates the wrapper code.

Thanks guys for the insightful input, I agree a more robust and elegant end solution would be to have SWIG auto-generate the appropriate Makefile.PL (or Build.PL) that will then be used to do the compilation and linking properly for one's environment.

I will work on this and present it to the SWIG people. For the time being they have at least updated the Perl quick tutorial which was broken to what I proposed and this has been tested. I know its only for systems with gcc but that is what their original commands had anyway so I guess no harm done.

I explained that this is for compiling a SWIG auto-generated XS and .pm binding code for specified C code, so it makes no sense to have to go through the additional hassle of creating and using a Makefile.PL when all you need are the gcc compile and gcc link commands that should be used for building a Perl module. ExtUtils::MakeMaker and Module::Build get the same gcc compile and gcc link flags from Perl core Config.pm no? They just put it into a Makefile as constants and during make they through them into the gcc compile and gcc link commands. I am doing the same but just shortcutting the parts I don't need.

The commands I provided produce the same gcc compile and link commands that you see when you install a CPAN module with C/C++ w/ XS code so how can this be wrong? Please check for yourself. The only flags that are excluded are not relevant to a SWIG Perl module build. CPAN modules with C/C++ w/ XS code are compiled like Perl itself was and should be, I don't know here if there is a misunderstanding here.

Backticks won't work on Windows, but then, I don't know whether SWIG will work on (non-Cygwin) Windows at all either.

And not all the world uses gcc.

Personally, I would go the route of least resistance and change the SWIG "build" process to produce a Makefile through ExtUtils::MakeMaker (see WriteMakefile() in ExtUtils::MakeMaker - this is a tried and true mechanism that will know about the appropriate C compiler to use with This Perl and will also know about the options needed.

Here is just one example of the commands when installing a CPAN module and using ExtUtils::MakeMaker:

/home/hermida/soft/perl/5.12.3/bin/perl /home/hermida/soft/perl/5.12.3
+/lib/5.12.3/ExtUtils/xsubpp -noprototypes -typemap /home/hermida/soft
+/perl/5.12.3/lib/5.12.3/ExtUtils/typemap -typemap typemap  Expat.xs >
+ Expat.xsc && mv Expat.xsc Expat.c

gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-p
+rotector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS
+=64 -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-prot
+ector --param=ssp-buffer-size=4 -m64 -mtune=native -march=native -g -
+DVERSION=\"2.40\" -DXS_VERSION=\"2.40\" -fPIC "-I/home/hermida/soft/p
+erl/5.12.3/lib/5.12.3/x86_64-linux-thread-multi/CORE" Expat.c

gcc -shared -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fsta
+ck-protector --param=ssp-buffer-size=4 -m64 -mtune=native -march=nati
+ve -g Expat.o  -o ../blib/arch/auto/XML/Parser/Expat/Expat.so
[download]

This is how all CPAN Perl modules with C + XS code compile and link (yes some have some extra flags that are just relevant to that particular module, but the all have these as the basis). The first command is not necessary for SWIG as you already have the C code and as I showed before swig -perl example.i autogenerates XS and .pm and other wrapping C code automatically. Let's breakdown the above parts that ExtUtils::MakeMaker created for this command:

gcc -c [Config-ccflags] [Config-optimize] [Config-cccdlflags] "-I[Conf
+ig-archlib]/CORE" module.c

gcc [Config-lddlflags] module.o -o module.so
[download]

This creates everything you need to create the Perl module and has been tested successfully by me and by SWIG people just yesterday. We ran Perl code using the modules and they work perfectly.

Please tell me why this is wrong in detail.

I was criticized by a person on the list saying "why in the world would you recommend using ExtUtils::MM that's so 15 years ago, you should use Module::Build, Module::Install or Dist::Zilla". I told him just because ExtUtils::MM is older for these purposes its just as capable and suitable as all the others mentioned. There are probably other reasons all of you mentioned using it instead of the others, even though the others are newer and have certain advantages.

I was then criticized for recommending that SWIG should auto-generate the Makefile.PL as it already auto-generates wrapper code and such. The reason was that SWIG doesn't generate any of these build helper files for the other languages (like the ant file for Java for example) then it shouldn't do it for Perl.

Sometimes I think why do I even try to help? This all started because the Perl quick start tutorial on the SWIG web site didn't even work and wasn't correct for building C/C++ code modules in Perl (and just to add that list user who said these recommendations are stupid never bothered to help and fix the tutorial!). So I fixed it by examining how ExtUtils::MM and others compile and link C/C++ code in Perl and as you guys know I recommended replacing the bad tutorial commands with those commands above. You guys then went one step further and recommended to me that its more robust to use a Makefile.PL and let ExtUtils::MM deal with the commands as it will do it better for each particular Perl installation, OS, environment, etc.

So these recommendations were made and I just get shut down. The user who said it was stupid to auto-generate a Makefile.PL said that people will just write what they want manually and they don't need it anyway. But I say why can't SWIG just generate a minimum correct Makefile.PL or Build.PL that by itself would at least correctly build the SWIG code since it auto-generates other code and files? Users can add/change to it if they want. I mean how hard is that? SWIG generates these other code files that need to be compiled and linked properly and nothing in order to do that. I totally disagree with this person that if you have a development tool that more easily integrates C/C++ code with your target language shouldn't it also come with the minimum file to properly build your code?

I don't think that if SWIG doesn't do it for any language that it shouldn't start. Thoughts?

So these recommendations were made and I just get shut down.

Pretty par for the course as far as mailing lists go. Incumbents invariably assume that a new name to the list couldn't possibly know more than they do. And woe betide you if you prove them wrong.

As likely as not you'll get banned for some unconnected irrelevance, like top posting or bottom posting or interleaving or not interleaving or quoting to little or too much or just cos its the third tuesday in the month.

And chances are if you stay quite and continue to monitor, someone will pick up your ideas a month or two from now, implement them as their idea and revel in the "glory".

The good news is that if you can live with that, and the ideas are any good, you'll often get what you wanted anyway.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.