Re: [HACKERS] About pgevent
If pgevent is a DLL, why is it in src/bin? We cannot have binary files like MSG1.bin in our source tree, no matter how convenient it is. The distributors are going to kill us for that. Please find another way. The discussion back when it was decided weighted things back and forth. The main thing is that we'd include an extra build dependency for win32, which would be the Microsoft toolkit, several hundred Mb to download just to build a 32 byte file. What distributors would kill us for that, and why? The file is only ever built (indeed, the whole directory is only *entered*) on win32. //Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] About pgevent
Magnus Hagander wrote: The discussion back when it was decided weighted things back and forth. The main thing is that we'd include an extra build dependency for win32, which would be the Microsoft toolkit, several hundred Mb to download just to build a 32 byte file. Think about what open source means. It doesn't mean that we give our users binary blobs compiled on some guy's machine, because it's too inconvenient to obtain the build tools. If it's too inconvenient to obtain build tools, you use a binary distribution anyway. On closer inspection this stuff should probably be moved to src/utils in any case. It's clearly not a user binary, so it doesn't belong under src/bin. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] About pgevent
The discussion back when it was decided weighted things back and forth. The main thing is that we'd include an extra build dependency for win32, which would be the Microsoft toolkit, several hundred Mb to download just to build a 32 byte file. Think about what open source means. It doesn't mean that we give our users binary blobs compiled on some guy's machine, because it's too inconvenient to obtain the build tools. If it's too inconvenient to obtain build tools, you use a binary distribution anyway. How is this so different from the fact that we distribute the configure script? People can just go download autoconf, right? Or flex/bison output files. If it's too inconvenient to obtain build tools, use a binary distribution. It's not like we don't provide the source. You can rebuild it if you want to. (Or just look at the file and realise it's probably nothing to worry about) On closer inspection this stuff should probably be moved to src/utils in any case. It's clearly not a user binary, so it doesn't belong under src/bin. Yeah, that doesn't sounds all wrong. It is of course a different issue alltogether... I *think* (but can't say I know) that the reason it went into src/bin was that there is no actual place for generic libs. interfaces and pl are, well, interfaces and pls. And utils/ don't currently install things. But it could certainly be moved there and installed from there, doesn't really matter. //Magnus ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] About pgevent
Peter Eisentraut [EMAIL PROTECTED] writes: Think about what open source means. It doesn't mean that we give our users binary blobs compiled on some guy's machine, because it's too inconvenient to obtain the build tools. If it's too inconvenient to obtain build tools, you use a binary distribution anyway. If I understand what the README is saying, pgmsgevent.mc is the source file (the preferred form for modification), and MSG1.bin is just prebuilt output from it. It's unpleasant that it's not text, but I don't see that this is fundamentally different from providing configure along with configure.in. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
