Обсуждение: MSVC
Now that we seem to have MSVC building working tolerably well, I think we need a bit of cleanup. In particular, I think the config setup needs to be more like the arguments we pass to the standard configure script. This shouldn't be hard, but I think it should be done before we go to beta, if possible. I think the names should match up pretty much one for one - this should make faking out pg_config easier. Since this is a perl hash, we'll need to have some sort of mapping convention. I suggest this: . where the configure arg doesn't take a value, make the hash value undef (e.g. '--enable-integer-datetimes' => undef ) . where the configure arg would occur with a single value, just set that (e.g. '--prefix' => 'c:\\foo' ) . where the configure arg would occur with a multiple value, provide a listref (e.g. '--with-libs' => [ 'c:\\bar', 'd:\\baz' ] ) Thoughts? cheers andrew
Andrew Dunstan wrote: > > > Now that we seem to have MSVC building working tolerably well, I think > we need a bit of cleanup. In particular, I think the config setup needs > to be more like the arguments we pass to the standard configure script. Why? I'm not saying I'm against it, I'd just like to know why? Personally, I find the store-in-a-file a whole lot more handy. > This shouldn't be hard, but I think it should be done before we go to > beta, if possible. I think the names should match up pretty much one for > one - this should make faking out pg_config easier. If we're changing it then yes, it's definitely better to do it before beta. > Since this is a perl hash, we'll need to have some sort of mapping > convention. I suggest this: > > . where the configure arg doesn't take a value, make the hash value > undef (e.g. '--enable-integer-datetimes' => undef ) Is there a way to differ that from just not being defined? otherwise, why not just make it 1 instead of undef? > . where the configure arg would occur with a single value, just set > that (e.g. '--prefix' => 'c:\\foo' ) > . where the configure arg would occur with a multiple value, provide a > listref (e.g. '--with-libs' => [ 'c:\\bar', 'd:\\baz' ] ) These I get. ;-) //Magnus
Magnus Hagander wrote: > Andrew Dunstan wrote: > >> Now that we seem to have MSVC building working tolerably well, I think >> we need a bit of cleanup. In particular, I think the config setup needs >> to be more like the arguments we pass to the standard configure script. >> > > Why? > I'm not saying I'm against it, I'd just like to know why? Personally, I > find the store-in-a-file a whole lot more handy. > I am only talking about the names. I want the hash key names to be the same as the configure argument names. >> Since this is a perl hash, we'll need to have some sort of mapping >> convention. I suggest this: >> >> . where the configure arg doesn't take a value, make the hash value >> undef (e.g. '--enable-integer-datetimes' => undef ) >> > > Is there a way to differ that from just not being defined? otherwise, > why not just make it 1 instead of undef? > I guess we can just handle 1/0, and if we detect one of those act appropriately - I don't think we have any cases where those would be expected values of configure arguments. > >> . where the configure arg would occur with a single value, just set >> that (e.g. '--prefix' => 'c:\\foo' ) >> . where the configure arg would occur with a multiple value, provide a >> listref (e.g. '--with-libs' => [ 'c:\\bar', 'd:\\baz' ] ) >> > > These I get. ;-) > > > > OK. I think we have a plan. Let's work on it. cheers andrew
Andrew Dunstan wrote: >> Why? >> I'm not saying I'm against it, I'd just like to know why? Personally, I >> find the store-in-a-file a whole lot more handy. >> > > I am only talking about the names. I want the hash key names to be the > same as the configure argument names. Oh, misunderstood you there. Then I have no objection :-) >>> Since this is a perl hash, we'll need to have some sort of mapping >>> convention. I suggest this: >>> >>> . where the configure arg doesn't take a value, make the hash value >>> undef (e.g. '--enable-integer-datetimes' => undef ) >>> >> >> Is there a way to differ that from just not being defined? otherwise, >> why not just make it 1 instead of undef? >> > > I guess we can just handle 1/0, and if we detect one of those act > appropriately - I don't think we have any cases where those would be > expected values of configure arguments. I think it would make things clearer. At least for those of us who don't breathe perl :-) //Magnus