[PATCH 1/2] libtracefs: clean also docs by default

[PATCH 1/2] libtracefs: clean also docs by default

[Krzysztof Kozlowski]

Logical is that `make clean` cleans everything done from build, not only
parts.  Leaving the documentation unclean requires additional step
when building for example Debian packages:

    $ dpkg-buildpackage -us -uc
    ...
    dpkg-source: info: local changes detected, the modified files are:

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 544684c1c37c..4650d15d64e9 100644
--- a/Makefile
+++ b/Makefile
@@ -375,6 +375,7 @@ samples: libtracefs.a force
 	$(Q)$(call descend,$(src)/samples,all)
 
 clean:
+	$(Q)$(call descend_clean,Documentation)
 	$(Q)$(call descend_clean,utest)
 	$(Q)$(call descend_clean,src)
 	$(Q)$(call descend_clean,samples)
-- 
2.32.0

[PATCH 2/2] libtracefs: fix utest linking path

[Krzysztof Kozlowski]

Build libraries are now in lib/.  This fixes test error:

    /usr/bin/ld: cannot find ..libtracefs/lib/tracefs/libtracefs.a: No such file or directory

Fixes: fe21539dc846 ("libtracefs: Build in the same directories as the source")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
---
 utest/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utest/Makefile b/utest/Makefile
index d168b01a328c..74bf7e60b91d 100644
--- a/utest/Makefile
+++ b/utest/Makefile
@@ -12,7 +12,7 @@ OBJS += tracefs-utest.o
 
 LIBS += -lcunit				\
 	-ldl				\
-	$(obj)/lib/tracefs/libtracefs.a
+	$(obj)/lib/libtracefs.a
 
 OBJS := $(OBJS:%.o=$(bdir)/%.o)
 DEPS := $(OBJS:$(bdir)/%.o=$(bdir)/.%.d)
-- 
2.32.0

Re: [PATCH 1/2] libtracefs: clean also docs by default

[Steven Rostedt]

On Mon, 24 Jan 2022 11:52:51 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:

> Logical is that `make clean` cleans everything done from build, not only
> parts.  Leaving the documentation unclean requires additional step
> when building for example Debian packages:
> 
>     $ dpkg-buildpackage -us -uc
>     ...
>     dpkg-source: info: local changes detected, the modified files are:

The reason we did this is because docs are not made by default.

(Yes you can say the same about utest, src and samples but those are all
code).

I've always kept the doc build (and cleanup) separate from the normal build.

Is it normal to remove the docs in other projects?

-- Steve



> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> ---
>  Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Makefile b/Makefile
> index 544684c1c37c..4650d15d64e9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -375,6 +375,7 @@ samples: libtracefs.a force
>  	$(Q)$(call descend,$(src)/samples,all)
>  
>  clean:
> +	$(Q)$(call descend_clean,Documentation)
>  	$(Q)$(call descend_clean,utest)
>  	$(Q)$(call descend_clean,src)
>  	$(Q)$(call descend_clean,samples)

Re: [PATCH 2/2] libtracefs: fix utest linking path

[Steven Rostedt]

On Mon, 24 Jan 2022 11:52:52 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:


Hi Krzysztof,

When submitting a patch, can you have the first word start with a capital
letter:

   "[PATCH 2/2] libtracefs: Fix utest linking path"


> Build libraries are now in lib/.  This fixes test error:
> 
>     /usr/bin/ld: cannot find ..libtracefs/lib/tracefs/libtracefs.a: No such file or directory
> 
> Fixes: fe21539dc846 ("libtracefs: Build in the same directories as the source")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> ---
>  utest/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/utest/Makefile b/utest/Makefile
> index d168b01a328c..74bf7e60b91d 100644
> --- a/utest/Makefile
> +++ b/utest/Makefile
> @@ -12,7 +12,7 @@ OBJS += tracefs-utest.o
>  
>  LIBS += -lcunit				\
>  	-ldl				\
> -	$(obj)/lib/tracefs/libtracefs.a
> +	$(obj)/lib/libtracefs.a

I was thinking how this failed for me. But I now see that my make clean
never removed the old directory and library.

Thanks for this! I'll apply it.

-- Steve


>  
>  OBJS := $(OBJS:%.o=$(bdir)/%.o)
>  DEPS := $(OBJS:$(bdir)/%.o=$(bdir)/.%.d)

Re: [PATCH 1/2] libtracefs: clean also docs by default

[Krzysztof Kozlowski]

On 04/02/2022 03:41, Steven Rostedt wrote:
> On Mon, 24 Jan 2022 11:52:51 +0100
> Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:
> 
>> Logical is that `make clean` cleans everything done from build, not only
>> parts.  Leaving the documentation unclean requires additional step
>> when building for example Debian packages:
>>
>>     $ dpkg-buildpackage -us -uc
>>     ...
>>     dpkg-source: info: local changes detected, the modified files are:
> 
> The reason we did this is because docs are not made by default.
> 
> (Yes you can say the same about utest, src and samples but those are all
> code).
> 
> I've always kept the doc build (and cleanup) separate from the normal build.
> 
> Is it normal to remove the docs in other projects?

I don't know actually, but I find natural that clean removes all
objects, even ones not created by "make all".

I see your point, so I do not insist on this solution. I can fix the
incomplete cleaning on Debian package side.

Best regards,
Krzysztof

Re: [PATCH 1/2] libtracefs: clean also docs by default

[Steven Rostedt]

On Fri, 4 Feb 2022 09:59:06 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:


> I don't know actually, but I find natural that clean removes all
> objects, even ones not created by "make all".

The main reason I like to keep documentation clean and code clean
separate, is because when I develop between different branches,
checking out an older one then a newer one, the make dependencies can
get screwed up. A make clean usually solves the issue when that
happens. But I don't want to rebuild the documentation every time I do
a make clean.

> 
> I see your point, so I do not insist on this solution. I can fix the
> incomplete cleaning on Debian package side.
> 

Great. I'll take the second patch and drop this one then.

Thanks for your contributions!

-- Steve