On Wed, Mar 21, 2018 at 05:22:07PM +0200, Michael S. Tsirkin wrote:
> Our rule right now is to use <> for external headers,
> "" for internal ones. The idea was to avoid conflicts
> between e.g. a system file named and an
> internal one by the same name.
>
> Unfortunately we use -I compiler flag
On Wed, Mar 21, 2018 at 06:40:23PM +0200, Marcel Apfelbaum wrote:
> On 21/03/2018 18:02, Michael S. Tsirkin wrote:
> > On Wed, Mar 21, 2018 at 03:36:51PM +, Daniel P. Berrangé wrote:
> >> On Wed, Mar 21, 2018 at 05:22:07PM +0200, Michael S. Tsirkin wrote:
> >>> Our rule right now is to use <> f
On 21/03/2018 18:02, Michael S. Tsirkin wrote:
> On Wed, Mar 21, 2018 at 03:36:51PM +, Daniel P. Berrangé wrote:
>> On Wed, Mar 21, 2018 at 05:22:07PM +0200, Michael S. Tsirkin wrote:
>>> Our rule right now is to use <> for external headers,
>>> "" for internal ones. The idea was to avoid confl
On Wed, Mar 21, 2018 at 03:36:51PM +, Daniel P. Berrangé wrote:
> On Wed, Mar 21, 2018 at 05:22:07PM +0200, Michael S. Tsirkin wrote:
> > Our rule right now is to use <> for external headers,
> > "" for internal ones. The idea was to avoid conflicts
> > between e.g. a system file named and an
On Wed, Mar 21, 2018 at 05:22:07PM +0200, Michael S. Tsirkin wrote:
> Our rule right now is to use <> for external headers,
> "" for internal ones. The idea was to avoid conflicts
> between e.g. a system file named and an
> internal one by the same name.
>
> Unfortunately we use -I compiler flag
Our rule right now is to use <> for external headers,
"" for internal ones. The idea was to avoid conflicts
between e.g. a system file named and an
internal one by the same name.
Unfortunately we use -I compiler flag so it does not
help: a system file doing #include will
still pick up ours first
