Re: Release stamping (Was: [CORE] Schedule for release?)

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Release stamping (Was: [CORE] Schedule for release?)
Дата
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA3582F@algol.sollentuna.se
обсуждение исходный текст
Ответ на Re: Release stamping (Was: [CORE] Schedule for release?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Release stamping (Was: [CORE] Schedule for release?)  ("Dave Page" <dpage@vale-housing.co.uk>)
Список pgsql-hackers
> >> The pg_config.h.win32 file is intended to support building in an
> >> environment where you can't run automake/autoconf, or
> indeed much of
> >> anything else.
>
> > That doesn't matter does it? Marc runs the bootstrap, which inserts
> > the version numbers into the right place and runs autoconf, then he
> > commits the changed files (configure, pg_config.h.win32
> etc) to CVS.
> > Only he (or you or Bruce) should ever need to run it.
>
> Hmm, so manufacture pg_config.h.win32 during tarball build
> and insert the version numbers at that point?  Yeah, that
> would work.  Actually the easiest thing would likely be to
> have configure build it the same way it builds pg_config.h,
> and then not remove it in "make distclean".

Getting late into this discussion, so I may be completely off here :-)
How's that going to work+ pg_config.h.win32 needs to know win32 platform
specifics, right? So it has to be created, in that case, on win32. But
when you're building with MSVC, you don't run configure, because windows
can't run that (without the mingw layer).

//Magnus


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: New CRC algorithm: Slicing by 8
Следующее
От: Andrew Sullivan
Дата:
Сообщение: Conference materials (Was: pdfs of the conference)