Submitted.
Note: Google groups word-wraps input, which can break patches.
On Tue, Sep 30, 2008 at 2:58 PM, Jeff Bailey <[EMAIL PROTECTED]> wrote:
>
> The following patch fixes one obsolete construct in configure.ac and
> neurotically adds quoting. Because I <3 m4.
>
> Tested with automake-1.9/a
Done.
On Tue, Sep 30, 2008 at 2:51 PM, Jeff Bailey <[EMAIL PROTECTED]> wrote:
>
> Heya Kenton,
>
> I played with the warning option a touch more, and if we do:
>
> autoreconf -f -i -Wall,no-obsolete
>
> it seems to give it without all the noise from old constructs in the
> libtool and automake M4
The following patch fixes one obsolete construct in configure.ac and
neurotically adds quoting. Because I <3 m4.
Tested with automake-1.9/autoconf2.59 and automake-1.10/autoconf2.61
index 203a2ff..4543e47 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7,10 +7,10 @@ AC_PREREQ(2.59)
# * java/p
Heya Kenton,
I played with the warning option a touch more, and if we do:
autoreconf -f -i -Wall,no-obsolete
it seems to give it without all the noise from old constructs in the
libtool and automake M4 macros. Checked with automake-1.9/
autoconf2.59 and automake1.10/autoconf2.61
On Sep 30, 1:
After some offline discussion I've gone ahead and submitted this.
On Tue, Sep 30, 2008 at 11:40 AM, Jeff Bailey <[EMAIL PROTECTED]> wrote:
>
> The autogen.sh script has all sorts of hardcoded magic in it,
> including the version of the autotools, and the fact that we're
> requiring "foriegn" mode
Kenton Varda escreveu:
> Our lawyer's opinion seems to be that the generated code is owned by the
> owner of the input file by default, even without a special note.
I have follwed similar discussions in many lists, and the conclusion is
allways that "generated code" is NOT "derived work" and
The reason I specified automake-1.9 explicitly is because our corp
workstations actually have the regular "automake" command linked to
automake-1.4, which is not good enough. automake-1.9 is installed on our
workstations, but is not the default. Can we somehow auto-detect this
situation and do so
The autogen.sh script has all sorts of hardcoded magic in it,
including the version of the autotools, and the fact that we're
requiring "foriegn" mode. With this patch, this will attempt to use
whatever the system autotools is, and also makes the foreign mode
explicit.
diff --git a/Makefile.am b
Our lawyer's opinion seems to be that the generated code is owned by the
owner of the input file by default, even without a special note. However,
I've added a note to COPYING.txt anyway to make it completely clear.
http://protobuf.googlecode.com/svn/trunk/COPYING.txt
On Tue, Sep 30, 2008 at 10:2
> The code generated by protoc requires linking against the protobuf
> libraries, so the Protocol Buffers license terms apply to you
> either way.
Ah, right. Thanks for reminding me of that.
> I can talk to our licensing people and get this clarified if you
> want, but given this, does i
I don't have any plans to support VC6, but if someone does the port and
submits a patch I'll be happy to apply it (assuming it doesn't harm other
platforms).
On Mon, Sep 29, 2008 at 8:37 PM, Angus <[EMAIL PROTECTED]> wrote:
>
> I'm working on several VC6 client server projects and want to migrate
The code generated by protoc requires linking against the protobuf
libraries, so the Protocol Buffers license terms apply to you either way. I
can talk to our licensing people and get this clarified if you want, but
given this, does it still matter? BTW, v2.0.2 (to be released later this
week) wi
Hi Kenton,
Protocol Buffers presents an unusual, but not unique/novel, situation
with respect to licensing.
Projects that use PB will often not actually include PB code in their
software (and often may not be re-distributing PB code in source or
compiled form), but rather, will be using t
13 matches
Mail list logo
