protobuf icon indicating copy to clipboard operation
protobuf copied to clipboard

Modify the protobuf files ASDF component?

Open rpgoldman opened this issue 9 years ago • 3 comments

In many cases, it's sufficient to distribute the lisp code generated by protobuf, and not require a library user to have the protocol buffer compiler installed locally. Any thoughts about how that might be done? Right now it seems that the .lisp files are generated into the cache by ASDF's compiled code relocation facility. We could make the .lisp files stay in the source directory instead, and then people could check them into repos, and not require the protocol buffer compiler be run.

rpgoldman avatar Nov 02 '16 20:11 rpgoldman

Hello ... at some point soon I'll take a look at the pull requests you have sent. Thanks very much for taking the time to send them.

Yes, the Lisp source code files generated by the protocol buffer compiler are written to the location where fasl files are written. If you want to include them in a project, you can just copy them from the fasl directory ... and introduce a build rule that treats them as normal Lisp code.

When I work on a project with ".proto" files, I generally do not want to see the Lisp intermediate files among my other source code ... that's why they live with the fasl files. I was also concerned that a user might edit one of the files, or otherwise change its modification time, which would cause trouble with ASDF's dependency management.

On Wed, Nov 2, 2016 at 4:03 PM, rpgoldman [email protected] wrote:

In many cases, it's sufficient to distribute the lisp code generated by protobuf, and not require a library user to have the protocol buffer compiler installed locally. Any thoughts about how that might be done? Right now it seems that the .lisp files are generated into the cache by ASDF's compiled code relocation facility. We could make the .lisp files stay in the source directory instead, and then people could check them into repos, and not require the protocol buffer compiler be run.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/brown/protobuf/issues/10, or mute the thread https://github.com/notifications/unsubscribe-auth/AABqsRs-AZuNd9WtZCyZB1w4kmAX6CNyks5q6OyDgaJpZM4Knr2g .

brown avatar Nov 02 '16 20:11 brown

I understand. However, we had a project where there are a number of developers, and we have a stable proto file (report.proto). So we wanted to jam the report.lisp into our ASDF system, and only regenerate it if the proto file had changed. That way developers who don't know protobuf aren't burdened with the installation of the compiler. This seems not unreasonable.

Maybe we could compromise by making the destination of the protobuf files somehow configurable (or, worst case, we could simply override this for our system). Then if the lisp file is new enough, one wouldn't try to run the compiler.

rpgoldman avatar Nov 02 '16 21:11 rpgoldman

Would another compromise option be to distribute pre-compiled protoc-gen-lisp executables with this repository and then modify the ASDF rules to run those directly? This would ensure that the .lisp files can be generated transparently by users without requiring any extra work.

A couple of options along these lines were suggested in this related issue thread: https://github.com/quicklisp/quicklisp-projects/issues/1806.

eschulte avatar Mar 22 '20 12:03 eschulte