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
Received on Mon Aug 18 15:54:36 2003