[Qemu-devel] [PATCH v2 15/20] migration: use local path for local headers

Michael S. Tsirkin posted 20 patches 7 years, 5 months ago
[Qemu-devel] [PATCH v2 15/20] migration: use local path for local headers
Posted by Michael S. Tsirkin 7 years, 5 months ago
When pulling in headers that are in the same directory as C file (as
opposed to one in include/), we should use its relative path, without a
directory. Directory based path works more or less by accident.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
 migration/block-dirty-bitmap.c | 2 +-
 migration/page_cache.c         | 2 +-
 migration/ram.c                | 4 ++--
 migration/vmstate.c            | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/migration/block-dirty-bitmap.c b/migration/block-dirty-bitmap.c
index 8819aab..eeccaff 100644
--- a/migration/block-dirty-bitmap.c
+++ b/migration/block-dirty-bitmap.c
@@ -66,7 +66,7 @@
 #include "qemu/error-report.h"
 #include "migration/misc.h"
 #include "migration/migration.h"
-#include "migration/qemu-file.h"
+#include "qemu-file.h"
 #include "migration/vmstate.h"
 #include "migration/register.h"
 #include "qemu/hbitmap.h"
diff --git a/migration/page_cache.c b/migration/page_cache.c
index 96268c3..acc252b 100644
--- a/migration/page_cache.c
+++ b/migration/page_cache.c
@@ -18,7 +18,7 @@
 #include "qapi/error.h"
 #include "qemu-common.h"
 #include "qemu/host-utils.h"
-#include "migration/page_cache.h"
+#include "page_cache.h"
 
 #ifdef DEBUG_CACHE
 #define DPRINTF(fmt, ...) \
diff --git a/migration/ram.c b/migration/ram.c
index 5bcbf7a..e7d6cf6 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -41,7 +41,7 @@
 #include "migration/misc.h"
 #include "qemu-file.h"
 #include "postcopy-ram.h"
-#include "migration/page_cache.h"
+#include "page_cache.h"
 #include "qemu/error-report.h"
 #include "qapi/error.h"
 #include "qapi/qapi-events-migration.h"
@@ -51,7 +51,7 @@
 #include "exec/target_page.h"
 #include "qemu/rcu_queue.h"
 #include "migration/colo.h"
-#include "migration/block.h"
+#include "block.h"
 #include "sysemu/sysemu.h"
 #include "qemu/uuid.h"
 #include "savevm.h"
diff --git a/migration/vmstate.c b/migration/vmstate.c
index 0b3282c..0a09636 100644
--- a/migration/vmstate.c
+++ b/migration/vmstate.c
@@ -14,7 +14,7 @@
 #include "qemu-common.h"
 #include "migration.h"
 #include "migration/vmstate.h"
-#include "migration/savevm.h"
+#include "savevm.h"
 #include "qemu-file.h"
 #include "qemu/bitops.h"
 #include "qemu/error-report.h"
-- 
MST


Re: [Qemu-devel] [PATCH v2 15/20] migration: use local path for local headers
Posted by Eric Blake 7 years, 5 months ago
On 05/25/2018 11:48 AM, Michael S. Tsirkin wrote:
> When pulling in headers that are in the same directory as C file (as

s/as C/as the C/ (here and in many other messages)

> opposed to one in include/), we should use its relative path, without a
> directory. Directory based path works more or less by accident.

Missed trimming this out of your commit message.

Or, if you want, on many of these commits, you could be more explicit 
about intention:

When pulling in headers that are in the same directory as the C file (as 
opposed to one in include/), we prefer to use its relative path without 
a directory, rather than relying on the global -I$(SRC_DIR) that may be 
removed in a later patch.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH v2 15/20] migration: use local path for local headers
Posted by Michael S. Tsirkin 7 years, 5 months ago
On Fri, May 25, 2018 at 01:24:08PM -0500, Eric Blake wrote:
> On 05/25/2018 11:48 AM, Michael S. Tsirkin wrote:
> > When pulling in headers that are in the same directory as C file (as
> 
> s/as C/as the C/ (here and in many other messages)

Will fix, thanks.

> > opposed to one in include/), we should use its relative path, without a
> > directory. Directory based path works more or less by accident.
> 
> Missed trimming this out of your commit message.

Will fix, thanks.

> Or, if you want, on many of these commits, you could be more explicit about
> intention:
> 
> When pulling in headers that are in the same directory as the C file (as
> opposed to one in include/), we prefer to use its relative path without a
> directory, rather than relying on the global -I$(SRC_DIR) that may be
> removed in a later patch.

I'm no longer sure we'll be able to.

> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] [PATCH v2 15/20] migration: use local path for local headers
Posted by Juan Quintela 7 years, 5 months ago
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> When pulling in headers that are in the same directory as C file (as
> opposed to one in include/), we should use its relative path, without a
> directory. Directory based path works more or less by accident.

I don't agree with the comment that they work by accident, it is
"by-design".  But if you want to change the design, I agree with
removing "$ROOT" from the default include path.

>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>

Later, Juan.

Re: [Qemu-devel] [PATCH v2 15/20] migration: use local path for local headers
Posted by Michael S. Tsirkin 7 years, 5 months ago
On Fri, May 25, 2018 at 08:27:03PM +0200, Juan Quintela wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > When pulling in headers that are in the same directory as C file (as
> > opposed to one in include/), we should use its relative path, without a
> > directory. Directory based path works more or less by accident.
> 
> I don't agree with the comment that they work by accident,

Oh I removed this from most commit messages but somehow this one managed
to sneek in.  I agree, will drop this sentence.

> it is
> "by-design".  But if you want to change the design, I agree with
> removing "$ROOT" from the default include path.
> 
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> Reviewed-by: Juan Quintela <quintela@redhat.com>
> 
> Later, Juan.

Thanks!