On 22/03/2018 20:29, Michael S. Tsirkin wrote:
> On Wed, Mar 21, 2018 at 05:22:03PM +0100, Kevin Wolf wrote:
>>> It's all still very much a non-standard convention and so less robust
>>> than prefixing file name with a project-specifix prefix.
>> I've always had the impression that it's by far the
On Wed, Mar 21, 2018 at 05:22:03PM +0100, Kevin Wolf wrote:
> > It's all still very much a non-standard convention and so less robust
> > than prefixing file name with a project-specifix prefix.
>
> I've always had the impression that it's by far the most common
> convention, to the point that I'd
Am 21.03.2018 um 16:58 hat Michael S. Tsirkin geschrieben:
> On Wed, Mar 21, 2018 at 04:34:39PM +0100, Kevin Wolf wrote:
> > Am 21.03.2018 um 15:46 hat Michael S. Tsirkin geschrieben:
> > > Our current scheme is to use
> > > #include ""
> > > for internal headers, and
> > > #include <>
> > > for
On Wed, Mar 21, 2018 at 04:34:39PM +0100, Kevin Wolf wrote:
> Am 21.03.2018 um 15:46 hat Michael S. Tsirkin geschrieben:
> > Our current scheme is to use
> > #include ""
> > for internal headers, and
> > #include <>
> > for external ones.
> >
> > Unfortunately this is not based on compiler suppo
On Wed, Mar 21, 2018 at 05:39:48PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 21, 2018 at 03:19:22PM +, Daniel P. Berrangé wrote:
> > On Wed, Mar 21, 2018 at 04:46:32PM +0200, Michael S. Tsirkin wrote:
> > > Our current scheme is to use
> > > #include ""
> > > for internal headers, and
> >
On Wed, Mar 21, 2018 at 03:19:22PM +, Daniel P. Berrangé wrote:
> On Wed, Mar 21, 2018 at 04:46:32PM +0200, Michael S. Tsirkin wrote:
> > Our current scheme is to use
> > #include ""
> > for internal headers, and
> > #include <>
> > for external ones.
> >
> > Unfortunately this is not based
Am 21.03.2018 um 15:46 hat Michael S. Tsirkin geschrieben:
> Our current scheme is to use
> #include ""
> for internal headers, and
> #include <>
> for external ones.
>
> Unfortunately this is not based on compiler support: from C point of
> view, the "" form merely looks up headers in the curre
On 21/03/2018 16:11, Michael S. Tsirkin wrote:
>> Can you explain the changes in the source tree layout?
> include/qemu -> include/qemu/common
> include/* -> include/qemu/*
Ok, then perhaps "util" instead of common would match the source layout
more.
Paolo
> Thus one uses any qemu headers with
>
On Wed, Mar 21, 2018 at 04:46:32PM +0200, Michael S. Tsirkin wrote:
> Our current scheme is to use
> #include ""
> for internal headers, and
> #include <>
> for external ones.
>
> Unfortunately this is not based on compiler support: from C point of
> view, the "" form merely looks up headers in
On Wed, Mar 21, 2018 at 04:04:29PM +0100, Paolo Bonzini wrote:
> On 21/03/2018 15:46, Michael S. Tsirkin wrote:
> > +if (m@^\s*#include\s+"qemu/@o) {
> > +s@^(\s*#include\s+)"qemu/([^"]+)"(.*)$@$1$3@o) {
> > +} else {
> > +s@^(\s*#include\s+)"([^"]+)"(.*)$@$1$3@o) {
> > +}
>
> Can you expl
On 21/03/2018 15:46, Michael S. Tsirkin wrote:
> +if (m@^\s*#include\s+"qemu/@o) {
> +s@^(\s*#include\s+)"qemu/([^"]+)"(.*)$@$1$3@o) {
> +} else {
> +s@^(\s*#include\s+)"([^"]+)"(.*)$@$1$3@o) {
> +}
Can you explain the changes in the source tree layout?
Also, s{}{} and m{} are a bit more
Our current scheme is to use
#include ""
for internal headers, and
#include <>
for external ones.
Unfortunately this is not based on compiler support: from C point of
view, the "" form merely looks up headers in the current directory
and then falls back on <> directories.
Thus, for example, a s
12 matches
Mail list logo
