----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1572/#review3732 -----------------------------------------------------------
Are you saying it would be necessary for the users to have protoc installed on their systems just to compile gem5 and use it? If that's the case, I am opposed to this change. I think this should be optional and not required, like the way we make use of google-perftools. - Nilay Vaish On Dec. 6, 2012, 8:19 p.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1572/ > ----------------------------------------------------------- > > (Updated Dec. 6, 2012, 8:19 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9367:e0c9aca8d292 > --------------------------- > scons: Add support for google protobuf building > > This patch enables the use of protobuf input files in the build > process, thus allowing .proto files to be added to input. Each .proto > file is compiled using the protoc tool and the newly created C++ > source is added to the list of sources. > > The first location where the protobufs will be used is in the > capturing and replay of memory traces, involving the communication > monitor and the trace-generator state of the traffic generator. This > will follow in the next patch. > > This patch does add a dependency on the availability of the BSD > licensed protobuf library (and headers), and the protobuf compiler, > protoc. These dependencies are checked in the SConstruct, similar to > e.g. swig. The user can override the use of protoc from the PATH by > specifying the PROTOC environment variable. > > Although the dependency on libprotobuf and protoc might seem like a > big step, they add significant value to the project going > forward. Execution traces and other types of traces could easily be > added and parsers for C++ and Python are automatically generated. We > could also envision using protobufs for the checkpoints, description > of the traffic-generator behaviour etc. The sky is the limit. We could > also use the GzipOutputStream from the protobuf library instead of the > current GPL gzstream. > > Currently, only the C++ source and header is generated. Going forward > we might want to add the Python output to support simple command-line > tools for displaying and editing the traces. > > > Diffs > ----- > > SConstruct 844f9e724343 > src/SConscript 844f9e724343 > > Diff: http://reviews.gem5.org/r/1572/diff/ > > > Testing > ------- > > util/regress all passing (disregarding t1000 and eio) > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
