Обсуждение: pgsql: Best-guess attempt at fixing MSVC build for 68ab8e8ba4a471d9.
Best-guess attempt at fixing MSVC build for 68ab8e8ba4a471d9. pgbench now needs to use src/bin/psql/psqlscan.l, but it's not very clear how to fit that into the MSVC build system. If this doesn't work I'm going to need some help from somebody who actually understands those scripts ... Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/6f1f34c92b11593ec62ff3e12781eb96dc911821 Modified Files -------------- src/tools/msvc/Mkvcbuild.pm | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
On 21 March 2016 at 10:52, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Best-guess attempt at fixing MSVC build for 68ab8e8ba4a471d9. > > pgbench now needs to use src/bin/psql/psqlscan.l, but it's not very clear > how to fit that into the MSVC build system. If this doesn't work I'm going > to need some help from somebody who actually understands those scripts ... I see this didn't fix the problem :-( Perl is not my native tongue, but after a little study and some testing on a windows machine, the attached seems to fix the problem. I've never much looked at these script before, but it seems that the parsing of the Makefile just assumes that psqlscan.c is in the same path as the rest of the stuff. The patch just uses some already defined file replace functions to switch the wrong filename out for the correct one before the Visual Studios project file is created. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
On 2016-03-21 22:38:50 +1300, David Rowley wrote: > On 21 March 2016 at 10:52, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Best-guess attempt at fixing MSVC build for 68ab8e8ba4a471d9. > > > > pgbench now needs to use src/bin/psql/psqlscan.l, but it's not very clear > > how to fit that into the MSVC build system. If this doesn't work I'm going > > to need some help from somebody who actually understands those scripts ... > > I see this didn't fix the problem :-( > > Perl is not my native tongue, but after a little study and some > testing on a windows machine, the attached seems to fix the problem. > > I've never much looked at these script before, but it seems that the > parsing of the Makefile just assumes that psqlscan.c is in the same > path as the rest of the stuff. The patch just uses some already > defined file replace functions to switch the wrong filename out for > the correct one before the Visual Studios project file is created. I've pushed this, as I would like the buildfarm to be green before pushing the latch rework... Maybe there's a better fix, but I think this is ok. Thanks! Andres
Andres Freund <andres@anarazel.de> writes:
> On 2016-03-21 22:38:50 +1300, David Rowley wrote:
>> Perl is not my native tongue, but after a little study and some
>> testing on a windows machine, the attached seems to fix the problem.
> I've pushed this, as I would like the buildfarm to be green before
> pushing the latch rework...
Thanks! If Andrew or somebody has a nicer solution, they can improve
this later.
Shouldn't we revert 6f1f34c92b11593e? AFAICS this patch isn't depending
on that, but maybe I miss something.
regards, tom lane
On 2016-03-21 09:25:18 -0400, Tom Lane wrote:
> Shouldn't we revert 6f1f34c92b11593e? AFAICS this patch isn't depending
> on that, but maybe I miss something.
Hm. I'd guess that at least part of it is still required. AddSimpleFrontend()
afaics processes these variables, and I don't think the msvc stuff will
otherwise generate psqlscan.c in the first place. We probably could
move the knowledge to the explicit AddSimpleFrontend('pgbench')
site. But I'm not personally excited about tinkering with it...
Andres
On 22 March 2016 at 02:33, Andres Freund <andres@anarazel.de> wrote:
> On 2016-03-21 09:25:18 -0400, Tom Lane wrote:
>> Shouldn't we revert 6f1f34c92b11593e? AFAICS this patch isn't depending
>> on that, but maybe I miss something.
>
> Hm. I'd guess that at least part of it is still required. AddSimpleFrontend()
> afaics processes these variables, and I don't think the msvc stuff will
> otherwise generate psqlscan.c in the first place. We probably could
> move the knowledge to the explicit AddSimpleFrontend('pgbench')
> site. But I'm not personally excited about tinkering with it...
Yeah, don't revert that. It half fixed things.
As far as I can see both your changes were needed. On testing it seems
the change to $frontend_extraincludes was required, but it all still
works after removing src/bin/psql/psqlscan.l from
$frontend_extrasource, although that's most likely only because psql
compiled first, and created psqlscan.c. So I think both changes are
required, we just end up running flex on psqlscan.l twice.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On 03/21/2016 09:25 AM, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: >> On 2016-03-21 22:38:50 +1300, David Rowley wrote: >>> Perl is not my native tongue, but after a little study and some >>> testing on a windows machine, the attached seems to fix the problem. >> I've pushed this, as I would like the buildfarm to be green before >> pushing the latch rework... > Thanks! If Andrew or somebody has a nicer solution, they can improve > this later. > I've reviewed the changes briefly. They seem sane enough, although the code could do with a little logical reordering. cheers andrew
On Tue, Mar 22, 2016 at 10:20 AM, Andrew Dunstan <andrew@dunslane.net> wrote: > > > On 03/21/2016 09:25 AM, Tom Lane wrote: >> >> Andres Freund <andres@anarazel.de> writes: >>> >>> On 2016-03-21 22:38:50 +1300, David Rowley wrote: >>>> >>>> Perl is not my native tongue, but after a little study and some >>>> testing on a windows machine, the attached seems to fix the problem. >>> >>> I've pushed this, as I would like the buildfarm to be green before >>> pushing the latch rework... >> >> Thanks! If Andrew or somebody has a nicer solution, they can improve >> this later. > > I've reviewed the changes briefly. They seem sane enough, although the code > could do with a little logical reordering. We're stuck with the list of files defined in OBJS, and psql's Makefile is listing psqlscan.o, so that's still the best way to go. -- Michael