constructor, and instead create an _internal_only getter
that gets the needed information. This is a workaround for
a deficiency in gcc-4.4 that does not properly support
templated friend classes.

- Add a protoc objc option (generate_for_named_framework) to set the name of
  the framework all generated sources will be in.
- Tweak some comments/naming to make it clear what is the Protobuf framework
  vs. the framework for generated code.
- Update the objc README to document the new generation option to protoc.

This is working towards https://github.com/google/protobuf/issues/1457.

Working on https://github.com/google/protobuf/issues/1599, specifically:
- Turn on more warnings that the Xcode UI calls out with individual controls.
- Manually add:
  -Wundef
  -Wswitch-enum
- Manually add and then diable in the unittests because of XCTest's headers:
  -Wreserved-id-macro
  -Wdocumentation-unknown-command
- Manually add -Wdirect-ivar-access, but disable it for the unittests and in
  the library code (via #pragmas to suppress it). This is done so proto users
  can enable the warning.

- Add generator constant for the default framework name.
- Add generator api for making the CPP symbol from the name.
- Add generator api to see if it is a bundled proto file.
- Output a CPP conditional and two imports for the core library headers.
- Add helper for generating the #import for file headers to deal with the
  framework imports.
- Add a reference from the unittests to a WKT to use that to inspect how
  imports generate.
- Update the podspec to define the CPP symbol and require pods 1.0 (or later).

Fixes https://github.com/google/protobuf/issues/1457

This got broken in commit 6ef984af
which integrated changes from internal branch.

The commit 3b3c8abb has replaced the <>
with "" in #include statement in js_generator.cc

As it may be implementation dependent.

This time move the macro inside namespaces; hopefully will work with the
integration script.

Added relative link to cmake guide.

proto2 syntax allows the first enum to have a non zero value. This means any
field using that default has a non zero default without having an explicit
default being set. So when deciding what runtime info is needed, don't rely
on an explicit default, always check that the values aren't zero.

Fixes https://github.com/google/protobuf/issues/1453

A protobuf message will be corrupted in the following scenario:
  1. Use LITE_RUNTIME.
  2. Have an optional enum field following some other field.
  3. Update protocol by adding new values to the enum.
  4. Have an old client parse and serialize a message having enum field
      set to a value the client does not understand.
  5. Field preceeding the enum is now corrupted.

The bug is due to the fact that optimized fallthrough in parser code
does not update variablle 'tag' when jumping to the parser code for the
next field.

Overview of changes:
- A new C#-specific command-line option, legacy_enum_values to revert to the old behavior
- When legacy_enum_values isn't specified, we strip the enum name as a prefix, and PascalCase the value name
- A new attribute within the C# code so that we can always tell the original in-proto name

Regenerating the C# code with legacy_enum_values leads to code which still compiles and works - but
there's more still to do.

proto3.

Added a couple unit test proto3 files, for arena_lite and lite. Cloned
the proto3_arena_unittest to test some of the basics of generated code
(and to ensure that the generated proto3 test files are used by some
test).

It doesn't seem to be necessary here, and it pulls other testing headers
during compilation of release protobuf.

This will make it easier to change the enum value names, as it reduces the number of places they're used.

This also renames generate_directories to base_namespace_specified; generating directories is the
immediate *effect* of specifying a base namespace, but with this change the options reflect what has been
specified rather than the effect. (There may be other effects in the future, of course.)

This should have no behavioral changes at all.

This doesn't strictly enforce an 80-column limit, but removes the most egregious violations.
The indentation in the C# generator code is inconsistent in general, unfortunately - if we have
any good tools that can be trusted to reformat, I'd be happy to apply them.

* `csharp_options`: Added `Options` to encapsulate generator options.
   Supported options for now - file_extension, base_namespace
* `{Blah}Generator`: Now accept `Options*` as parameter to constructor
* `csharp_generator.cc`: Parse and populate options
* `Makefile.am`: Added `csharp_options.h`
* `extract_includes.bat.in`: Added `csharp_options.h`

Refactoring code to two commits. This is the first commit

For fixing MSVC

stubs/common.h undefines the GetMessage macro introduced in windows.h
map_test however include stubs/common.h before windows.h is transitively
included. This hack force map_test.cc to include windows.h first, so we
have a chance to undefine the GetMessage macro.