Anything the system doesn't pick up automatically. That means most new build targets (but it will pick up a contrib automatically, and a conversion proc, for example). Also if modifications are made to the scripts that run (like gen_fmgr.sh).
Just adding new files to exisitng makefiles, or adding a new subdir that adds more files to an existing target, should require no changes. //Magnus Bruce Momjian wrote: > Exactly what type of changes affec the MSVC build system? > > --------------------------------------------------------------------------- > > Magnus Hagander wrote: >> Tom Lane wrote: >>> Peter Eisentraut <pete...@gmx.net> writes: >>>> On Tuesday 16 December 2008 16:53:26 Tom Lane wrote: >>>>> I do not think this is an appropriate attitude for a committer to take. >>>> I would like to have this clarified, as I keep running afoul of it. >>> My two cents: I don't expect you to fix the MSVC scripts if you are >>> uninterested in doing so. But it would be appropriate to post a note >>> to -hackers when you make a build system change that is going to need >>> to be reflected in those scripts. The people who do care about MSVC >>> should not have to find that out by watching the buildfarm and then >>> trying to reverse-engineer the cause of a failure. >> As one of said people, I think that's perfectly reasonable. It'd make it >> a lot easier to get a heads-up, or just the version of the patch right >> before a commit to add it to. Some people do that, some don't - it would >> be muchos helpful if all did. >> >> I don't expect unix hackers to always patch the msvc system as needed - >> given that you don't have a way to test it, and no experience how those >> tools work. (I know Tom has made a number of smaller fixes in them, but >> it's mostly been around the areas of smaller changes, not actually >> adding new stuff, for exmaple) >> >> If I had warning this time, for example, I could've said that I for one >> can't fix that for a while, because my msvc build system is all geared >> up around the git server (because it's so much easier to get the stuff >> in and out of the VM when cross-deveoping than with CVS and the crippled >> commandline toolchain on windows). And since that one is currently not >> working properly, I need to find a different way to get the code in >> there unless someone can fix it :-( >> >> Hopefully someone else can pick it up this time around? If not, I'll do >> it as soon as I get things back up and working in my env. >> >> //Magnus >> >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
