Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4210189pxu; Mon, 12 Oct 2020 12:21:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyVb6pbsHH/v1CoggjJOpMJseaSIGCT5iuc7U+lbU9fONpYQfshOXEpE9j9gViPRy/Je19f X-Received: by 2002:a50:9b14:: with SMTP id o20mr15307157edi.328.1602530515647; Mon, 12 Oct 2020 12:21:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602530515; cv=none; d=google.com; s=arc-20160816; b=qbxtjQmY5m93Of8+rgZTcfuHeKQ2d+GmluV0+s6UaHX4bjHhu4jSFN91Bt7a1bxxJg f6212OnLhSlvuaG7HnaYtZ3oPI9F/hxHI3njKGF+vYMtbKqbvdOcijYtdt+1nCxWrKvH cUevamvbjVvRMYA9X2TIpiSlInmX00fTSkN602tc1PG55jS0nf6nupK7O7Nlegaro4C5 OicalaNzDJai6PSNlTiYmzWQk0RuoFyyd8qWs5S06SKqpQTA2McB3GPzvSiEaO4OTeXc JWG4zTqJWZwXALuaO2Qfl7KAhRzSxId6KUjNkiWQub2ZJKxwaNsZyGRf4LOxkK9gxefz 27/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=08oRYTCWtDxMJH+tQ43zWvQDzcx5KrwpLRAbp9Yb9Q0=; b=wGAaemPc87OQdjmuomO/ansD8V6vCRPKTVvU1KTQ2MtFYyKMIhkm4s+Gex8VJmIEjS h+6+UwJsrs4GSFdGZ86Ui1C/XNMu9MYY7/SbJ6KXR6kvCnI1Kq7namAVIPaZK2HnXRdx bNwXZ1ZWmivEhAJNyuHgq0gM0XeuUgRIw5tJ9HfuQtlxs6DeJRa83p7xuTPmXGrHaEIr d0aPr6nQYdQ2RA6Te20VtQSW7FBDppweRBuG/ZgBpMjN/xm0y2fnmhdyIR3KP9DAdEbu +CQbzjNiQFcV5rIN0TeF0bitgJBV0LHE0no9Ee+UkYp64aCx+kOI3FK2V/mSVDGjUMbD MiMw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t3si4862585edw.568.2020.10.12.12.21.31; Mon, 12 Oct 2020 12:21:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403794AbgJLTRh (ORCPT + 99 others); Mon, 12 Oct 2020 15:17:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:59940 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730857AbgJLTRh (ORCPT ); Mon, 12 Oct 2020 15:17:37 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 216172074A; Mon, 12 Oct 2020 19:17:34 +0000 (UTC) Date: Mon, 12 Oct 2020 15:17:32 -0400 From: Steven Rostedt To: Tony Jones Cc: Jiri Olsa , LKML , Linux Trace Devel , Zamir SUN , Arnaldo Carvalho de Melo , zsun@redhat.com, Vitaly Chikunov , Tzvetomir Stoyanov , Yordan Karadzhov , Ben Hutchings , Sudip Mukherjee , John Kacur , Clark Williams , Al Stone , Mauro Carvalho Chehab Subject: Re: [ANNOUNCE] libtraceevent.git Message-ID: <20201012151732.6e439886@gandalf.local.home> In-Reply-To: <20201012184120.GN13697@suse.de> References: <20201007130750.49349844@gandalf.local.home> <20201012101208.GF1099489@krava> <20201012111950.55a73588@gandalf.local.home> <20201012184120.GN13697@suse.de> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ Removing the powertop mailing list because it's rejecting everything ] On Mon, 12 Oct 2020 11:41:20 -0700 Tony Jones wrote: > On Mon, Oct 12, 2020 at 11:19:50AM -0400, Steven Rostedt wrote: > > > Once it's shown that it works for all the package maintainers, I will tag > > it which should create the tarballs automatically on the above link. > > Hi. > > It builds fine for me after manually creating the tarball from git. > Once there is an official versioned tarball I'll push it into > openSUSE. > > I presume some perf Makefile changes will be forthcoming to use it, > rather than continuing to force build it out of TRACE_EVENT_DIR > Zamir found this issue with the Documentation man pages: Note, I'm not sure the proper way to fix this. I think this is the last issue I need to resolve before making the tag. -- Steve On Thu, 8 Oct 2020 17:50:19 +0800 Zamir SUN wrote: > Hi, > > When I try to compiling the document of libtraceevent with the fix I > mentioned in [1] applied, make doc-install fails with errors like > > "/usr/bin/install: cannot stat 'libtraceevent-record_parse.3': No such > file or directory" > > Checking the compiled documents I see a lot of tep_*.3 generated, and > some libtraceevent_*.html. However no libtraceevent_*.3. > > $ ls Documentation/*3 | head > Documentation/libtraceevent.3 > Documentation/tep_alloc.3 > Documentation/tep_clear_flag.3 > Documentation/tep_cmdline_pid.3 > Documentation/tep_data_comm_from_pid.3 > Documentation/tep_data_flags.3 > Documentation/tep_data_pid.3 > Documentation/tep_data_pid_from_comm.3 > Documentation/tep_data_preempt_count.3 > Documentation/tep_data_type.3 > ls Documentation/*html | head > Documentation/libtraceevent-commands.html > Documentation/libtraceevent-cpus.html > Documentation/libtraceevent-endian_read.html > Documentation/libtraceevent-event_find.html > Documentation/libtraceevent-event_get.html > Documentation/libtraceevent-event_list.html > Documentation/libtraceevent-event_print.html > Documentation/libtraceevent-field_find.html > Documentation/libtraceevent-field_get_val.html > Documentation/libtraceevent-field_print.html > > I also tried to port the Makefile from trace-cmd/Documentation to the > document dir, and it still only generates tep_*.3 files, so I feel this > is not the issue with the patch from [1]. > > As for my local environment, I have xmlto and asciidoc installed[2], but > not asciidoctor. I expect asciidoc could generate the documentations > like what it did in trace-cmd before. > > Any idea if this is issue with my environment or it's something that > need to be implemented in the Makefile? > Hi Zamir, Thanks a lot for looking into this. I took your advice and reverted my blind copy of the Makefiles, scripts and include headers, and instead copied over their full history from the Linux kernel Tools directory. You can see that update no (which now includes the utilities.mak as well). Can you see if this patch fixes your current issue? -- Steve diff --git a/Documentation/Makefile b/Documentation/Makefile index edb8623..3a981be 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -157,7 +157,7 @@ endif do-install-man: man $(call QUIET_INSTALL, Documentation-man) \ $(INSTALL) -d -m 755 $(DESTDIR)$(man3dir); \ - $(INSTALL) -m 644 $(DOC_MAN3) $(DESTDIR)$(man3dir); + $(INSTALL) -m 644 $(OUTPUT)*.3 $(DESTDIR)$(man3dir); install-man: check-man-tools man do-install-man