Hi,
No feedback to recent proposed patch release to the mailing list, so this has now been published as v.0.8.4
Mike
On 2 May 2018 at 16:09, Mike Leach mike.leach@linaro.org wrote:
Hi Wookey,
For some reason the .patch files again would not apply - but they were simple so a manual merge got the results.
On 27 April 2018 at 03:55, Wookey wookey@wookware.org wrote:
On 2018-04-13 10:18 +0100, Mike Leach wrote:
[Apols for slow response: I've been on hols for a week]
On 12 April 2018 at 19:04, Wookey wookey@wookware.org wrote:
On 2018-04-11 23:13 +0100, Mike Leach wrote:
I've attached an updated patchset - largely based on your patches, adjusted to fix the above issues
The final upstream patchset will contain additional stuff (some expanded user docs and a couple of source fixes that have been made since 0.8.1), but if you could check that this set doesn't break the packaging build, then we will be almost there.
OK, I need a one-line patch to make it work,
-OCSD_ROOT := $(shell pwd | sed 's,/build/linux.*,,') +OCSD_ROOT := $(CURDIR)/decoder
No - you did add it to one of the previous patches - but it broke the build I have been using since the start of the project. i.e. cd <opencsd-checkout-dir>/decoder/build/linux make
using $(CURDIR) assumes that build is being run from the root of the project - if I run as normal from the build directory $(CURDIR) is opencsd-checkout-dir>/decoder/build/linux, and that is uses as a basis for the rest of the make process, thus awk looking for a none-existent decode sub-dir in build/linux.
If you need to run from the root of the project it is possible using make -C decoder/build/linux
Not sure from the description above precisely how you are launching the makefile, or why it breaks using the existing makefile.
I've been doing make -f decoder/build/linux/makefile LIB_PATH=$(LIB_PATH)
I hadn't realised it was expected/necessary to change into that subdir to do the build - it explains the layout with the makefile not at the top of the source tree. Is there a reason why that is preferable to the more conventional makefile-at-the-top? Having the makefile in the same dir as the $ROOT from which build paths are generated avoids this whole issue of having to find the root from where the makefile is (because it's 'here').
I see there is a clue in decoder/docs/build_libs.md, but I didn't grok from that that it was _only_ expected to work from that dir.
"Go to the `./build/linux/` and run `make` in that directory."
Anyway, doing make -C decoder/build/linux DEBUG=1 LIB_PATH=$(LIB_PATH) works fine for the debian build, so that's workable.
However - here's a better solution. This works whatever dir you are in, and for all of: cd build/linux; make make -f decoder/build/linux/makefile make -C decoder/build/linux
It uses the location of the makefile, not the present working directory, to find the root, which is always correct: -OCSD_ROOT := $(shell pwd | sed 's,/build/linux.*,,') +OCSD_ROOT := $(shell echo $(dir $(abspath $(lastword $(MAKEFILE_LIST)))) | sed 's,/build/linux.*,,')
patch attached.
'Applied' thanks - this works well.
Also the doc build is not getting cleaned: -clean: clean_libs clean_tests +clean: clean_libs clean_tests clean_docs
Actually, I am happy with not building docs by default, and hence not cleaning by default - and doing both as a specific make task, just as I would with install. I rarely build docs during development - just when looking at a final release.
I understand that, but you can leave the clean target in at essentially no cost. It just cleans up nothing in the default case. Is that really a problem? Using a -f to avoid the (ignored) error message makes sense in this case: -rm -rf $(OCSD_ROOT)/docs/html
everything else looks sensible, except I'd do: ( cd $(LIB_TARGET_DIR); ln -sf $(LIB_NAME).so.$(SO_VER) $(LIB_NAME).so.$(SO_MAJOR_VER) )
rather than ( cd $(LIB_TARGET_DIR); rm -f $(LIB_NAME).so.$(SO_MAJOR_VER); ln -s $(LIB_NAME).so.$(SO_VER) $(LIB_NAME).so.$(SO_MAJOR_VER) )
I added in the 'rm ...' command to prevent an error killing partial builds during the development process.
but -sf does exactly that too, more succinctly. I've tested it here for partial (upstream9style) builds and it works. Is it not working for you? Have I misunderstood something?
I think I must have missed the -sf when I manually merged the last set. -sf works just fine thanks.
The last issue was that I got errors for 'make clean_install':-
rm /usr/lib/libopencsd.{so,a} rm: cannot remove '/usr/lib/libopencsd.{so,a}': No such file or directory
Not sure exactly where this came from but seems that particular .{so.a} syntax is upsetting the system so is now
-rm $(INSTALL_LIB_DIR)/lib$(LIB_BASE_NAME).* -rm $(INSTALL_LIB_DIR)/lib$(LIB_CAPI_NAME).*So with that I think we have a patchset I can upstream that should work for your packaging environment as well as my development systems. I'll be updating the build_libs.md file first as this is now somewhat out of date, but expect to post a "final" patchset to the list imminently.
Thanks for your help on this.
Regards
Mike
Wookey
Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK