Include addconfig.ac from backends/extensions directories in configur… #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…e.ac; rerun create-makefile.am.sh if anything is out of date
sethfowler
added a commit
to sethfowler/p4c
that referenced
this pull request
May 2, 2017
The main refactoring taking place in this PR is to port the P4-14 and P4-16 lexers and parsers to use the C++ modes of Flex and Bison. In C++ mode, Flex generates a lexer that reads from a `std::istream` object instead of a file descriptor. That produces a bit of an impedance mismatch, because typically before we parse anything we run it through the C preprocessor via `popen()`, and `popen()` uses C `FILE*`-based I/O rather than iostreams. The C++-11 standard library does not include a `FILE*` wrapper that produces an `std::istream`. If we don't want to write and maintain one ourselves (and I'd argue we don't) that leaves us with three options: 1. Stop using `popen()` and implement the subset of C preprocessor features we need directly. 2. Read the entire file in and wrap it in a `std::stringstream` or similar. This obviously isn't as efficient as it could be. 3. Use Boost's IOStreams library to do the job more efficiently. In the large term, my view is that p4lang#1 is the best choice, but in the short run p4lang#3 seems like a win with no real downsides other than adding another dependency. (It's only an additional dependency on Ubuntu, which splits Boost into a number of small packages. On macOS there's actually no change.) In the interest of getting this PR landed ASAP, I've actually implemented both p4lang#2 and p4lang#3, so the Boost IOStreams dependency is optional. I would vastly prefer to make it mandatory, though.
sethfowler
added a commit
to sethfowler/p4c
that referenced
this pull request
May 3, 2017
The main refactoring taking place in this PR is to port the P4-14 and P4-16 lexers and parsers to use the C++ modes of Flex and Bison. In C++ mode, Flex generates a lexer that reads from a `std::istream` object instead of a file descriptor. That produces a bit of an impedance mismatch, because typically before we parse anything we run it through the C preprocessor via `popen()`, and `popen()` uses C `FILE*`-based I/O rather than iostreams. The C++-11 standard library does not include a `FILE*` wrapper that produces an `std::istream`. If we don't want to write and maintain one ourselves (and I'd argue we don't) that leaves us with three options: 1. Stop using `popen()` and implement the subset of C preprocessor features we need directly. 2. Read the entire file in and wrap it in a `std::stringstream` or similar. This obviously isn't as efficient as it could be. 3. Use Boost's IOStreams library to do the job more efficiently. In the large term, my view is that p4lang#1 is the best choice, but in the short run p4lang#3 seems like a win with no real downsides other than adding another dependency. (It's only an additional dependency on Ubuntu, which splits Boost into a number of small packages. On macOS there's actually no change.) In the interest of getting this PR landed ASAP, I've actually implemented both p4lang#2 and p4lang#3, so the Boost IOStreams dependency is optional. I would vastly prefer to make it mandatory, though.
sethfowler
added a commit
to sethfowler/p4c
that referenced
this pull request
May 4, 2017
The main refactoring taking place in this PR is to port the P4-14 and P4-16 lexers and parsers to use the C++ modes of Flex and Bison. In C++ mode, Flex generates a lexer that reads from a `std::istream` object instead of a file descriptor. That produces a bit of an impedance mismatch, because typically before we parse anything we run it through the C preprocessor via `popen()`, and `popen()` uses C `FILE*`-based I/O rather than iostreams. The C++-11 standard library does not include a `FILE*` wrapper that produces an `std::istream`. If we don't want to write and maintain one ourselves (and I'd argue we don't) that leaves us with three options: 1. Stop using `popen()` and implement the subset of C preprocessor features we need directly. 2. Read the entire file in and wrap it in a `std::stringstream` or similar. This obviously isn't as efficient as it could be. 3. Use Boost's IOStreams library to do the job more efficiently. In the large term, my view is that p4lang#1 is the best choice, but in the short run p4lang#3 seems like a win with no real downsides other than adding another dependency. (It's only an additional dependency on Ubuntu, which splits Boost into a number of small packages. On macOS there's actually no change.) In the interest of getting this PR landed ASAP, I've actually implemented both p4lang#2 and p4lang#3, so the Boost IOStreams dependency is optional. I would vastly prefer to make it mandatory, though.
sethfowler
added a commit
to sethfowler/p4c
that referenced
this pull request
May 4, 2017
The main refactoring taking place in this PR is to port the P4-14 and P4-16 lexers and parsers to use the C++ modes of Flex and Bison. In C++ mode, Flex generates a lexer that reads from a `std::istream` object instead of a file descriptor. That produces a bit of an impedance mismatch, because typically before we parse anything we run it through the C preprocessor via `popen()`, and `popen()` uses C `FILE*`-based I/O rather than iostreams. The C++-11 standard library does not include a `FILE*` wrapper that produces an `std::istream`. If we don't want to write and maintain one ourselves (and I'd argue we don't) that leaves us with three options: 1. Stop using `popen()` and implement the subset of C preprocessor features we need directly. 2. Read the entire file in and wrap it in a `std::stringstream` or similar. This obviously isn't as efficient as it could be. 3. Use Boost's IOStreams library to do the job more efficiently. In the large term, my view is that p4lang#1 is the best choice, but in the short run p4lang#3 seems like a win with no real downsides other than adding another dependency. (It's only an additional dependency on Ubuntu, which splits Boost into a number of small packages. On macOS there's actually no change.) In the interest of getting this PR landed ASAP, I've actually implemented both p4lang#2 and p4lang#3, so the Boost IOStreams dependency is optional. I would vastly prefer to make it mandatory, though.
sethfowler
added a commit
that referenced
this pull request
May 4, 2017
The main refactoring taking place in this PR is to port the P4-14 and P4-16 lexers and parsers to use the C++ modes of Flex and Bison. In C++ mode, Flex generates a lexer that reads from a `std::istream` object instead of a file descriptor. That produces a bit of an impedance mismatch, because typically before we parse anything we run it through the C preprocessor via `popen()`, and `popen()` uses C `FILE*`-based I/O rather than iostreams. The C++-11 standard library does not include a `FILE*` wrapper that produces an `std::istream`. If we don't want to write and maintain one ourselves (and I'd argue we don't) that leaves us with three options: 1. Stop using `popen()` and implement the subset of C preprocessor features we need directly. 2. Read the entire file in and wrap it in a `std::stringstream` or similar. This obviously isn't as efficient as it could be. 3. Use Boost's IOStreams library to do the job more efficiently. In the large term, my view is that #1 is the best choice, but in the short run #3 seems like a win with no real downsides other than adding another dependency. (It's only an additional dependency on Ubuntu, which splits Boost into a number of small packages. On macOS there's actually no change.) In the interest of getting this PR landed ASAP, I've actually implemented both #2 and #3, so the Boost IOStreams dependency is optional. I would vastly prefer to make it mandatory, though.
pzanna
added a commit
to pzanna/p4c
that referenced
this pull request
Dec 5, 2020
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…e.ac; rerun create-makefile.am.sh if anything is out of date