You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2003/08/11 22:32:54 UTC
Re: svn commit: rev 6686 - trunk/build/generator
rey4@tigris.org wrote:
>Author: rey4
>Date: Sat Aug 9 12:18:45 2003
>New Revision: 6686
>
>Modified:
> trunk/build/generator/gen_win.py
>Log:
>Visual Studio projects for perl bindings now link with the perl library.
>The perl command used to figure out the library name came from
>Branko Cibej <br...@xbc.nu> and Colin Watson <cj...@flatline.org.uk>.
>
>* build/generator/gen_win.py
> (WinGeneratorBase.__init__): now detects library name for installed
> perl version
>
> (WinGeneratorBase.get_win_libs): now includes perl library
>
>+ else:
>+ self.perl_lib = 'perl56.lib'
>+ sys.stderr.write('Could not detect perl version. Perl bindings will\n'
>+ ' be linked with %s\n' % self.perl_lib)
>
If you can't detect the version of Perl, then most likely the user
either doesn't have it installed, or it's not on the PATH. In any case,
script generation should abort and the user should figure out what's
wrong. Generating project files that you know won't work isn't right.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6686 - trunk/build/generator
Posted by Russell Yanofsky <re...@columbia.edu>.
Branko Čibej wrote:
> Russell Yanofsky wrote:
>
>> Branko Čibej wrote:
>>
>>
>>> Generating project files that you know won't work isn't
>>> right.
>>>
>>>
>>
>> The resulting project file will work if the user later installs Perl
>> 5.6. And anyway, I think generating a project file that might not
>> work is preferable to not generating any project file at all.
>>
> No, it's not, see below.
>
>> Let's say a user
>> builds Subversion and later installs Perl 5.8. If he then opens up
>> visual studio to build the Perl bindings, isn't it be better for him
>> to see the __SWIG_PERL__ project and get a sensible error message
>> like 'Library perl56.lib not found'
>>
> And the user then bombards the dev@ lists with questions about why his
> perl bindings don't build. I've seen too many of these kinds of
> problems. That's why we have (or should have) flags: --enable-perl,
> --enable-python, etc. They can either be off by default, or enabled
> iff both SWIG and the scriptiong language are installed.
I don't understand. If a user wants to build the swig bindings and he can't
do it, isn't he going to post to the list no matter what?
IMO, determining whether to generate project files based on command line
arguments and autodetection is more confusing to users than just generating
the same project files all the time.
>> when he tries to build it than for him to open the
>> workspace and not see the project listed at all? In the first case
>> the user at least has an error message to go on, in the second case
>> he's likely to wonder if its possible to build the Perl bindings at
>> all in Visual Studio.
>>
> Exactly my point, but with a different twist. If we know the bindings
> won't build, why bother to generate the project?
We don't know the bindings won't build. The project file will work with Perl
5.6. And even if it doesn't work (because Perl isn't installed correctly or
a different version of Perl is installed) it means the user will see a
Visual C++ error message describing the problem instead of being left to
wonder why there's no project file.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6686 - trunk/build/generator
Posted by Branko Čibej <br...@xbc.nu>.
Russell Yanofsky wrote:
>Branko Čibej wrote:
>
>
>>Generating project files that you know won't work isn't
>>right.
>>
>>
>
>The resulting project file will work if the user later installs Perl 5.6.
>And anyway, I think generating a project file that might not work is
>preferable to not generating any project file at all.
>
No, it's not, see below.
> Let's say a user
>builds Subversion and later installs Perl 5.8. If he then opens up visual
>studio to build the Perl bindings, isn't it be better for him to see the
>__SWIG_PERL__ project and get a sensible error message like 'Library
>perl56.lib not found'
>
And the user then bombards the dev@ lists with questions about why his
perl bindings don't build. I've seen too many of these kinds of
problems. That's why we have (or should have) flags: --enable-perl,
--enable-python, etc. They can either be off by default, or enabled iff
both SWIG and the scriptiong language are installed.
> when he tries to build it than for him to open the
>workspace and not see the project listed at all? In the first case the user
>at least has an error message to go on, in the second case he's likely to
>wonder if its possible to build the Perl bindings at all in Visual Studio.
>
Exactly my point, but with a different twist. If we know the bindings
won't build, why bother to generate the project?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 6686 - trunk/build/generator
Posted by Russell Yanofsky <re...@columbia.edu>.
Branko Čibej wrote:
> rey4@tigris.org wrote:
>
>> Author: rey4
>> Date: Sat Aug 9 12:18:45 2003
>> New Revision: 6686
>>
>> Modified:
>> trunk/build/generator/gen_win.py
>> Log:
>> Visual Studio projects for perl bindings now link with the perl
>> library. The perl command used to figure out the library name came
>> from Branko Cibej <br...@xbc.nu> and Colin Watson
>> <cj...@flatline.org.uk>.
>>
>> * build/generator/gen_win.py
>> (WinGeneratorBase.__init__): now detects library name for
>> installed perl version
>>
>> (WinGeneratorBase.get_win_libs): now includes perl library
>>
>> + else:
>> + self.perl_lib = 'perl56.lib'
>> + sys.stderr.write('Could not detect perl version. Perl
>> bindings will\n' + ' be linked with %s\n' %
>> self.perl_lib)
>>
> If you can't detect the version of Perl, then most likely the user
> either doesn't have it installed, or it's not on the PATH. In any
> case, script generation should abort and the user should figure out
> what's wrong.
Since the only thing Perl is needed for is building the Perl bindings, it
doesn't make much sense to halt everything just because it isn't found. The
Perl detection I added is exactly like the Berkeley DB detection. If it
works, the detected value is used, otherwise a reasonable default is used,
and either way a status message gets printed with the results of
autodetection.
> Generating project files that you know won't work isn't
> right.
The resulting project file will work if the user later installs Perl 5.6.
And anyway, I think generating a project file that might not work is
preferable to not generating any project file at all. Let's say a user
builds Subversion and later installs Perl 5.8. If he then opens up visual
studio to build the Perl bindings, isn't it be better for him to see the
__SWIG_PERL__ project and get a sensible error message like 'Library
perl56.lib not found' when he tries to build it than for him to open the
workspace and not see the project listed at all? In the first case the user
at least has an error message to go on, in the second case he's likely to
wonder if its possible to build the Perl bindings at all in Visual Studio.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org