From: Leandro H. <so...@le...> - 2011-03-23 18:25:22
|
Hi, When running through the SWIG tutorial on the web site when I get to the Perl module build step I get the following error: % ld -G swig_example.o swig_example.o -o swig_example.so /usr/bin/ld: swig_example.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC swig_example.o: could not read symbols: Bad value collect2: ld returned 1 exit status Am I doing something wrong or is the tutorial out-of-date? |
From: <man...@be...> - 2011-03-24 07:23:43
|
I used to have the same problem. Try this: gcc -fPIC -c swig_example.c swig_example_wrap.c `perl -MExtUtils::Embed -e ccopts` ________________________________ Von: Leandro Hermida [mailto:so...@le...] Gesendet: Mittwoch, 23. März 2011 19:03 An: swi...@li... Betreff: [Swig-user] SWIG Tutorial doesn't work for building Perl module example Hi, When running through the SWIG tutorial on the web site when I get to the Perl module build step I get the following error: % ld -G swig_example.o swig_example.o -o swig_example.so /usr/bin/ld: swig_example.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC swig_example.o: could not read symbols: Bad value collect2: ld returned 1 exit status Am I doing something wrong or is the tutorial out-of-date? |
From: Leandro H. <so...@le...> - 2011-03-25 14:01:22
|
Hello everyone, Ok so the Perl Module Building tutorial might need to be updated. My first question is, in Perl when you compile and link and C code to use via XS you need to use the same compiling and linking flags that were used to build Perl itself. Why with the SWIG Perl module building are we not doing the same? You will find that in CPAN any modules that you install with XS C/C++ code always do their compile and link commands like this: gcc -c <ccflags> <optimize flags> <cccdlflags> module.c gcc <lddlflags> module.o -o module.so I've left out certain options that aren't important for SWIG. The cccdlflags have -fPIC. In order to get all of the flags above that were used to build Perl the module ExtUtils::Embed doesn't have all of these so we need to use the Perl core Config.pm module that comes with Perl and gives you access to all original Perl configuration information. So I believe the Perl compiling and linking SWIG tutorial commands after the swig -perl example.i command should now be: gcc -c `perl -MConfig -e 'print join(" ", @Config{qw(ccflags optimize cccdlflags)}, "-I$Config{archlib}/CORE")'` example.c example_wrap.c gcc `perl -MConfig -e 'print @Config{qw(lddlflags)}'` example.o example_wrap.o -o example.so The lddlflags already has the -G/-shared option for the second linking command so we don't need that. I've tested the tutorial with these new commands and it works perfectly, after the compile command you only get these normal warnings now: example_wrap.c: In function ‘SWIG_Perl_ConvertPtr’: example_wrap.c:1101: warning: value computed is not used example_wrap.c: In function ‘SWIG_Perl_MakePtr’: example_wrap.c:1123: warning: value computed is not used example_wrap.c: In function ‘boot_example’: example_wrap.c:1974: warning: unused variable ‘items’ What do you guys think? best, Leandro On Thu, Mar 24, 2011 at 8:23 AM, <man...@be...> wrote: > I used to have the same problem. > > Try this: > gcc -fPIC -c swig_example.c swig_example_wrap.c `perl -MExtUtils::Embed > -e ccopts` > > > ------------------------------ > *Von:* Leandro Hermida [mailto:so...@le...] > *Gesendet:* Mittwoch, 23. März 2011 19:03 > *An:* swi...@li... > *Betreff:* [Swig-user] SWIG Tutorial doesn't work for building Perl module > example > > Hi, > > When running through the SWIG tutorial on the web site when I get to the > Perl module build step I get the following error: > > % ld -G swig_example.o swig_example.o -o swig_example.so > > /usr/bin/ld: swig_example.o: relocation R_X86_64_32 against `a local > symbol' can not be used when making a shared object; recompile with -fPIC > swig_example.o: could not read symbols: Bad value > collect2: ld returned 1 exit status > > Am I doing something wrong or is the tutorial out-of-date? > |
From: William S F. <ws...@fu...> - 2011-03-25 20:03:05
|
Thanks for suggestions. I've updated the tutorial as suggested. Please check it and confirm it is correct. I don't get those warnings though with latest SWIG. William On 25/03/11 13:31, Leandro Hermida wrote: > Hello everyone, > > Ok so the Perl Module Building tutorial might need to be updated. My > first question is, in Perl when you compile and link and C code to use > via XS you need to use the same compiling and linking flags that were > used to build Perl itself. Why with the SWIG Perl module building are > we not doing the same? You will find that in CPAN any modules that you > install with XS C/C++ code always do their compile and link commands > like this: > > gcc -c <ccflags> <optimize flags> <cccdlflags> module.c > gcc <lddlflags> module.o -o module.so > > I've left out certain options that aren't important for SWIG. The > cccdlflags have -fPIC. > > In order to get all of the flags above that were used to build Perl the > module ExtUtils::Embed doesn't have all of these so we need to use the > Perl core Config.pm module that comes with Perl and gives you access to > all original Perl configuration information. > > So I believe the Perl compiling and linking SWIG tutorial commands after > the swig -perl example.i command should now be: > > gcc -c `perl -MConfig -e 'print join(" ", @Config{qw(ccflags optimize > cccdlflags)}, "-I$Config{archlib}/CORE")'` example.c example_wrap.c > gcc `perl -MConfig -e 'print @Config{qw(lddlflags)}'` example.o > example_wrap.o -o example.so > > The lddlflags already has the -G/-shared option for the second linking > command so we don't need that. > > I've tested the tutorial with these new commands and it works perfectly, > after the compile command you only get these normal warnings now: > > example_wrap.c: In function ‘SWIG_Perl_ConvertPtr’: > example_wrap.c:1101: warning: value computed is not used > example_wrap.c: In function ‘SWIG_Perl_MakePtr’: > example_wrap.c:1123: warning: value computed is not used > example_wrap.c: In function ‘boot_example’: > example_wrap.c:1974: warning: unused variable ‘items’ > > What do you guys think? > > best, > Leandro > > > On Thu, Mar 24, 2011 at 8:23 AM, <man...@be... > <mailto:man...@be...>> wrote: > > I used to have the same problem. > Try this: > gcc -fPIC -c swig_example.c swig_example_wrap.c `perl > -MExtUtils::Embed -e ccopts` > > ------------------------------------------------------------------------ > *Von:* Leandro Hermida [mailto:so...@le... > <mailto:so...@le...>] > *Gesendet:* Mittwoch, 23. März 2011 19:03 > *An:* swi...@li... > <mailto:swi...@li...> > *Betreff:* [Swig-user] SWIG Tutorial doesn't work for building Perl > module example > > Hi, > > When running through the SWIG tutorial on the web site when I get to > the Perl module build step I get the following error: > > % ld -G swig_example.o swig_example.o -o swig_example.so > > /usr/bin/ld: swig_example.o: relocation R_X86_64_32 against `a local > symbol' can not be used when making a shared object; recompile with > -fPIC > swig_example.o: could not read symbols: Bad value > collect2: ld returned 1 exit status > > Am I doing something wrong or is the tutorial out-of-date? > > > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > > > > _______________________________________________ > Swig-user mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user |
From: Leandro H. <so...@le...> - 2011-03-26 15:24:56
|
On Fri, Mar 25, 2011 at 9:02 PM, William S Fulton <ws...@fu...>wrote: > Thanks for suggestions. I've updated the tutorial as suggested. Please > check it and confirm it is correct. I don't get those warnings though with > latest SWIG. > > William > > Hi William - sorry I forgot to say that I tested it with swig 1.3.29 on RHEL5 which came from swig rpm package. I'm glad with 2.0.x these warnings are fixed -Leandro |
From: Leandro H. <so...@le...> - 2011-03-31 14:06:47
|
Hi again, I've discussed the SWIG Perl module build process with various people on PerlMonks.org and they recommended a more robust and appropriate solution to building Perl modules in SWIG which is to generate a Makefile.PL and use ExtUtils::MakeMaker to do the build process. This is the de facto standard method by which all Perl CPAN modules build themselves when you install them and it's robust since ExtUtils::MakeMaker takes care of finding for you exactly how to generate the correct build commands and options for your Perl installation, environment and OS, etc. ExtUtils::MakeMaker is part of the Perl distribution so everyone who has Perl has it. Now the recommendation is to have SWIG auto-generate the Makefile.PL and a couple other necessary files during the swig -perl example.i command. Then users do the typical Perl module building and installing commands: perl Makefile.PL make make install What I need to provide for you is a representative SWIG Perl module Makefile.PL and the other necessary files and show what parts can be variable for the SWIG auto-generate process to know what to do. Does this sound like a good idea you all of you? BTW the updated commands I provided earlier are still good and correct for the "quick start tutorial" as they fix what was there before and manually do the same thing that ExtUtils::MakeMaker actually does in a gcc compiler environment. regards, Leandro On Sat, Mar 26, 2011 at 4:24 PM, Leandro Hermida <so...@le... > wrote: > > On Fri, Mar 25, 2011 at 9:02 PM, William S Fulton <ws...@fu... > > wrote: > >> Thanks for suggestions. I've updated the tutorial as suggested. Please >> check it and confirm it is correct. I don't get those warnings though with >> latest SWIG. >> >> William >> >> > Hi William - sorry I forgot to say that I tested it with swig 1.3.29 on > RHEL5 which came from swig rpm package. I'm glad with 2.0.x these warnings > are fixed > > -Leandro > |
From: Vadim Z. <vz...@ze...> - 2011-03-31 14:43:17
|
On Thu, 31 Mar 2011 16:06:38 +0200 Leandro Hermida <so...@le...> wrote: LH> I've discussed the SWIG Perl module build process with various people on LH> PerlMonks.org and they recommended a more robust and appropriate solution to LH> building Perl modules in SWIG which is to generate a Makefile.PL and use LH> ExtUtils::MakeMaker to do the build process. This is strange because ExtUtils::MakeMaker is almost certainly not the best choice for doing it right now (as opposed to 15 years ago). A more recent well known and better (even according to the ExtUtils::MakeMaker maintainer himself) alternative is Module::Build and there are others: Module::Install and, especially, the latest (AFAIK) one: Dist::Zilla. I'd probably use Dist::Zilla myself for any new project right now as a lot of people I respect in Perl community recommend it but even if you disagree with these recommendations you should at least realize that EU::MM is very far from being an undisputed standard for Perl modules development. LH> Now the recommendation is to have SWIG auto-generate the Makefile.PL LH> and a couple other necessary files during the swig -perl example.i LH> command. I don't think it's reasonable to expect SWIG to do it. It doesn't generate ant files for Java, for example, why should it generate Makefile.PL for Perl? And at least ant _is_ the standard for Java while if you decide to generate Makefile.PL you really have no justification for not generating the files for the other Perl build frameworks. LH> What I need to provide for you is a representative SWIG Perl module LH> Makefile.PL and the other necessary files and show what parts can be LH> variable for the SWIG auto-generate process to know what to do. Does this LH> sound like a good idea you all of you? I think my point of view should be clear by now :-) LH> BTW the updated commands I provided earlier are still good and correct for LH> the "quick start tutorial" as they fix what was there before and manually do LH> the same thing that ExtUtils::MakeMaker actually does in a gcc compiler LH> environment. The quick start tutorial is good for what it is, I think. The documentation should mention that any real project should use one of the full-featured Perl build systems but that's about as far as SWIG should go. Regards, VZ |
From: Leandro H. <so...@le...> - 2011-03-31 15:55:13
|
On Thu, Mar 31, 2011 at 4:42 PM, Vadim Zeitlin <vz...@ze...> wrote: > On Thu, 31 Mar 2011 16:06:38 +0200 Leandro Hermida < > so...@le...> wrote: > > LH> I've discussed the SWIG Perl module build process with various people > on > LH> PerlMonks.org and they recommended a more robust and appropriate > solution to > LH> building Perl modules in SWIG which is to generate a Makefile.PL and > use > LH> ExtUtils::MakeMaker to do the build process. > > This is strange because ExtUtils::MakeMaker is almost certainly not the > best choice for doing it right now (as opposed to 15 years ago). A more > recent well known and better (even according to the ExtUtils::MakeMaker > maintainer himself) alternative is Module::Build and there are others: > Module::Install and, especially, the latest (AFAIK) one: Dist::Zilla. > I apologize but you are not correct here, just because something is older doesn't mean it's not the most widely used still and perfectly suitable to do the job. Most Perl CPAN distributions today use ExtUtils::MakeMaker still over Module::Build or Module::Install, just pay attention to the output when you are installing your distros via CPAN.pm, CPANPLUS, cpanminus, whatever. Yes you are right in terms of building Dist::Zilla is very much the same as the others, but it doesn't do any installation and is not really intended for the purpose we are talking about here. Dist::Zilla is a toolkit if you are a CPAN author and want to setup and build your distribution for *upload* to CPAN, this is what its main purpose is. I also think its total overkill for Perl SWIG needs. Please read my thread on PerlMonks http://www.perlmonks.org/?node_id=895499where all the recommendations made were to use ExtUtils::MakeMaker for the purpose of building Perl modules for SWIG. And I do agree with them it suits the job perfectly and does the exact same job as the other distros mentioned. Yes there are some advantages in cetain situations to using Module::Build (pure Perl, no system make needed, easier to do custom extensions) and Module::Install (which is simply a wrapper around ExtUtils::MakeMaker :) with some additional features and different syntax in Makefile.PL) but from what I see none of those features are really needed for Perl SWIG. I'd probably use Dist::Zilla myself for any new project right now as a lot > of people I respect in Perl community recommend it but even if you disagree > with these recommendations you should at least realize that EU::MM is very > far from being an undisputed standard for Perl modules development. > ExtUtils::MM is one of the standards for building *and* installing, the other two being Module::Build and Module::Install but ExtUtils::MM is still the most used on CPAN. LH> Now the recommendation is to have SWIG auto-generate the Makefile.PL > LH> and a couple other necessary files during the swig -perl example.i > LH> command. > > I don't think it's reasonable to expect SWIG to do it. It doesn't generate > ant files for Java, for example, why should it generate Makefile.PL for > Perl? And at least ant _is_ the standard for Java while if you decide to > generate Makefile.PL you really have no justification for not generating > the files for the other Perl build frameworks. > > Using the tutorial as an example this is how ridiculously simple the ExtUtils::MM Makefile.PL is: use ExtUtils::MakeMaker; WriteMakefile( NAME => 'example', C => ['example.c', 'example_wrap.c'], OBJECT => 'swig_example.o swig_example_wrap.o', ); That's all you need to build everything properly with automatic detection of the exact compilation and linking commands for your Perl installation, environment, OS, etc. Plus if you want you get installation of your SWIG code into your Perl tree with a couple more options. I really don't think this is too much to ask SWIG to auto-generate as part of its Perl process. If one prefers a Module::Build Build.PL file or a Module::Install Makefile.PL they too are super short and simple. In terms of SWIG there is absolutely no difference between the three, no one does better than the other and their build commands are exactly the same. > LH> What I need to provide for you is a representative SWIG Perl module > LH> Makefile.PL and the other necessary files and show what parts can be > LH> variable for the SWIG auto-generate process to know what to do. Does > this > LH> sound like a good idea you all of you? > > I think my point of view should be clear by now :-) > > LH> BTW the updated commands I provided earlier are still good and correct > for > LH> the "quick start tutorial" as they fix what was there before and > manually do > LH> the same thing that ExtUtils::MakeMaker actually does in a gcc compiler > LH> environment. > > The quick start tutorial is good for what it is, I think. The > documentation should mention that any real project should use one of the > full-featured Perl build systems but that's about as far as SWIG should go. > > I disagree, I think if one wants and auto-generated Makefile.PL or Build.PL then SWIG should be able to provide it because it is so easy. > Regards, > VZ > |
From: Vadim Z. <vz...@ze...> - 2011-03-31 16:22:35
|
On Thu, 31 Mar 2011 17:55:04 +0200 Leandro Hermida <so...@le...> wrote: LH> > This is strange because ExtUtils::MakeMaker is almost certainly not the LH> > best choice for doing it right now (as opposed to 15 years ago). A more LH> > recent well known and better (even according to the ExtUtils::MakeMaker LH> > maintainer himself) alternative is Module::Build and there are others: LH> > Module::Install and, especially, the latest (AFAIK) one: Dist::Zilla. LH> LH> I apologize but you are not correct here, just because something is older LH> doesn't mean it's not the most widely used still and perfectly suitable to LH> do the job. Sorry, but I didn't say it wasn't the most widely used. And it might be suitable too. But you will find very few new projects using EU::MM still and I still maintain that most influential people in Perl community don't recommend it since a long time because newer alternative are all better than "raw" EU::MM (yes, M::I just builds on top of it but the point is that you still don't write Makefile.PL yourself when using it). In any case, I don't think this is the right place to discuss this nor, to be honest, if it's interesting to have this discussion at all, as this is at least partly a subjective choice. The point is that EU::MM is definitely not the undisputed standard. LH> Using the tutorial as an example this is how ridiculously simple the LH> ExtUtils::MM Makefile.PL is: So people using EU::MM will be perfectly able to create it themselves. And people using M::B will be able to write Build.PL themselves too. LH> I really don't think this is too much to ask SWIG to auto-generate as LH> part of its Perl process. I definitely think it is for all the reasons I gave. Basically: 1. It doesn't do it for any other language AFAIK and I don't see why should Perl be special. 2. There is no obvious choice of the output to generate for Perl and it would be a madness to plan to generate them all. LH> I disagree, I think if one wants and auto-generated Makefile.PL or Build.PL LH> then SWIG should be able to provide it because it is so easy. SWIG is not the right tool for this and adding support for EU::MM to SWIG itself would arguably be counter productive because it will be useful only to people not knowing much about build Perl projects (because more knowledgeable people would use some other system for new modules and would be more than able to write a simple Makefile.PL if they do need it) and so would push them to use EU::MM which is a bad idea in this day and age. But please don't concentrate on the EU::MM legacy arguments, even if you disagree with them (although I've not seen anything explaining why, you only say that it's the most widely used one but this is quite different from being the best one), I think the (1) above is even more important and sufficient for not doing this. Regards, VZ |
From: William S F. <ws...@fu...> - 2011-04-01 23:55:13
|
On 31/03/11 16:55, Leandro Hermida wrote: > On Thu, Mar 31, 2011 at 4:42 PM, Vadim Zeitlin <vz...@ze... > <mailto:vz...@ze...>> wrote: > > On Thu, 31 Mar 2011 16:06:38 +0200 Leandro Hermida > <so...@le... <mailto:so...@le...>> wrote: > > LH> I've discussed the SWIG Perl module build process with various > people on > LH> PerlMonks.org and they recommended a more robust and appropriate > solution to > LH> building Perl modules in SWIG which is to generate a Makefile.PL > and use > LH> ExtUtils::MakeMaker to do the build process. > > This is strange because ExtUtils::MakeMaker is almost certainly > not the > best choice for doing it right now (as opposed to 15 years ago). A more > recent well known and better (even according to the ExtUtils::MakeMaker > maintainer himself) alternative is Module::Build and there are others: > Module::Install and, especially, the latest (AFAIK) one: Dist::Zilla. > > > I apologize but you are not correct here, just because something is > older doesn't mean it's not the most widely used still and perfectly > suitable to do the job. Most Perl CPAN distributions today use > ExtUtils::MakeMaker still over Module::Build or Module::Install, just > pay attention to the output when you are installing your distros via > CPAN.pm, CPANPLUS, cpanminus, whatever. Yes you are right in terms of > building Dist::Zilla is very much the same as the others, but it doesn't > do any installation and is not really intended for the purpose we are > talking about here. Dist::Zilla is a toolkit if you are a CPAN author > and want to setup and build your distribution for *upload* to CPAN, this > is what its main purpose is. I also think its total overkill for Perl > SWIG needs. > > Please read my thread on PerlMonks > http://www.perlmonks.org/?node_id=895499 where all the recommendations > made were to use ExtUtils::MakeMaker for the purpose of building Perl > modules for SWIG. And I do agree with them it suits the job perfectly > and does the exact same job as the other distros mentioned. Yes there > are some advantages in cetain situations to using Module::Build (pure > Perl, no system make needed, easier to do custom extensions) and > Module::Install (which is simply a wrapper around ExtUtils::MakeMaker :) > with some additional features and different syntax in Makefile.PL) but > from what I see none of those features are really needed for Perl SWIG. > > I'd probably use Dist::Zilla myself for any new project right now as > a lot > of people I respect in Perl community recommend it but even if you > disagree > with these recommendations you should at least realize that EU::MM > is very > far from being an undisputed standard for Perl modules development. > > > ExtUtils::MM is one of the standards for building *and* installing, the > other two being Module::Build and Module::Install but ExtUtils::MM is > still the most used on CPAN. > > LH> Now the recommendation is to have SWIG auto-generate the Makefile.PL > LH> and a couple other necessary files during the swig -perl example.i > LH> command. > > I don't think it's reasonable to expect SWIG to do it. It doesn't > generate > ant files for Java, for example, why should it generate Makefile.PL for > Perl? And at least ant _is_ the standard for Java while if you decide to > generate Makefile.PL you really have no justification for not generating > the files for the other Perl build frameworks. > > > Using the tutorial as an example this is how ridiculously simple the > ExtUtils::MM Makefile.PL is: > > use ExtUtils::MakeMaker; > > WriteMakefile( > NAME => 'example', > C => ['example.c', 'example_wrap.c'], > OBJECT => 'swig_example.o swig_example_wrap.o', > ); > > That's all you need to build everything properly with automatic > detection of the exact compilation and linking commands for your Perl > installation, environment, OS, etc. Plus if you want you get > installation of your SWIG code into your Perl tree with a couple more > options. I really don't think this is too much to ask SWIG to > auto-generate as part of its Perl process. If one prefers a > Module::Build Build.PL file or a Module::Install Makefile.PL they too > are super short and simple. In terms of SWIG there is absolutely no > difference between the three, no one does better than the other and > their build commands are exactly the same. > > LH> What I need to provide for you is a representative SWIG Perl module > LH> Makefile.PL and the other necessary files and show what parts can be > LH> variable for the SWIG auto-generate process to know what to do. > Does this > LH> sound like a good idea you all of you? > > I think my point of view should be clear by now :-) > > LH> BTW the updated commands I provided earlier are still good and > correct for > LH> the "quick start tutorial" as they fix what was there before and > manually do > LH> the same thing that ExtUtils::MakeMaker actually does in a gcc > compiler > LH> environment. > > The quick start tutorial is good for what it is, I think. The > documentation should mention that any real project should use one of the > full-featured Perl build systems but that's about as far as SWIG > should go. > > > I disagree, I think if one wants and auto-generated Makefile.PL or > Build.PL then SWIG should be able to provide it because it is so easy. SWIG is not going to get involved in build systems, there are too many ways to do this and too many complications. For example, with your suggestion above, how is SWIG going to know what to use for runpath options, platform specific user chosen compiler options, additional modules to link with, statically or dynamically, alternative linkers, eg gold, integrating with other build systems that a user is already using to compile their code, such as CMake, bjam etc, work with a common build system a user will need for perl, java, go, tcl etc wrappers of the same library? All these configurations and pile of build problems are one for users to sort out. However, some documentation on suggested approaches to building a target language is perfectly acceptable and to that end, I suggest you send us a patch to Doc/Manual/Perl.html with this information. William |
From: Leandro H. <so...@le...> - 2011-04-05 23:53:55
|
On Sat, Apr 2, 2011 at 1:54 AM, William S Fulton <ws...@fu...>wrote: > > SWIG is not going to get involved in build systems, there are too many ways > to do this and too many complications. For example, with your suggestion > above, how is SWIG going to know what to use for runpath options, platform > specific user chosen compiler options, additional modules to link with, > statically or dynamically, alternative linkers, eg gold, integrating with > other build systems that a user is already using to compile their code, such > as CMake, bjam etc, work with a common build system a user will need for > perl, java, go, tcl etc wrappers of the same library? All these > configurations and pile of build problems are one for users to sort out. > However, some documentation on suggested approaches to building a target > language is perfectly acceptable and to that end, I suggest you send us a > patch to Doc/Manual/Perl.html with this information. > Hi, I was intending that SWIG would create the *minimum standard* Makefile.PL (ExtUtils::MM or Module::Install) or Build.PL (Module::Build) that will successfully and correctly compile and link the code. In Perl many of the things you mentioned like runpath options, platform specific user chosen compiler options, etc are known automatically and completely done for you by the Perl build tools I mentioned because they know how to correctly build C/C++ code for your particular Perl installation, environment, OS, etc. Perl modules with C/C++ and XS code need to be compiled and linked with the same options as Perl itself was. I can understand the other things you said yes this would be too complicated, but doing the minimum build file that works properly for the target language is easy and the user can add or change that afterwards. Currently SWIG leaves users in the cold after auto-generating the code and a beginner or whatever would definitely have problems figuring out how to do the rest properly for the target language. For example the Perl build quick tutorial was all wrong and didn't even work and I am surprised that Vadim or other Perlers didn't bother to send the fix, I a fairly new SWIG user worked it out and sent it. Too me I don't mind if you choose not to go with the recommendation, it was just a suggestion that I find useful because SWIG should auto-generate minimum needed to get it to at least build properly in the target language, not leave the user to have to figure all that out in the middle. |