Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
> > > >I will look into making a xenomai.pc file. > > > > > > Make it a xenomai.pc.in file ;-) Yes, that's what I considered doing. > > I am not sure we want to depend on pkg-config... > > Gilles, put it the other way around. Xenomai won't depend on > pkg-config, but applications using Xenomai, will happily > depend on it, if they choose this option. To me, pkg-config > shouldn't be a replacement, but an alternative choice to > xeno-config. I agree, it considered that as an alternative. Unfortunately, it is not that simple. It would be necessary to create several *.pc.in files, one for each set of config parameters, cf. the output of xeno-config: - xenomai-kernel.pc.in <-> --kernel-* - xenomai-native.pc.in <-> --xeno-* - xenomai-posix.pc.in <-> --posix-* - xenomai-uvm.pc.in <-> --uvm-* Beware that me must "merge" the *-cflags and *-ldflags config info, because pkg-config splits them a-posteriori, cf. the --cflags, --libs-only-L and --libs-only-l options of pkg-config. That separation is different from that of Xenomai's xeno-config. And the xeno-config script would still be necessary for some parameters, such as: xeno-config --module-dir and: xeno-config --config pkg-config is too limited regarding the information that we can put into .pc files... Anyway, Stephane, if you want to write the four *.pc.in, go on please! :) -- Romain Lenglet
RE: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Fillod Stephane wrote: > Romain Lenglet wrote: > [..] > >I found a better solution, that could be a replacement for both a > >xenomai.m4 trick, and the xeno-config script: pkg-config. > >http://pkgconfig.freedesktop.org/wiki/ > >There are packages for pkgconfig in both Debian and RedHat, > >AFAIK, and surely for all other distribs. > > > >I will look into making a xenomai.pc file. > > Make it a xenomai.pc.in file ;-) I am not sure we want to depend on pkg-config... -- Gilles Chanteperdrix.
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
> > A simpler solution would be to ship a xenomai.m4 to be used > > as a acinclude.m4 in every project using Xenomai. But I > > have had very bad experiences with aclocal in that use > > case. aclocal is quite buggy. And it would be more > > confortable for projects it is were immediately available > > after installing Xenomai. > > Yes, this was the original plan, but there are still many > things on our todo list before that. I found a better solution, that could be a replacement for both a xenomai.m4 trick, and the xeno-config script: pkg-config. http://pkgconfig.freedesktop.org/wiki/ There are packages for pkgconfig in both Debian and RedHat, AFAIK, and surely for all other distribs. I will look into making a xenomai.pc file. > DESTDIR is used by xeno-config the same way it is used by > Makefiles. When you compiled Xenomai for a target and > installed it with DESTDIR=/home/romain/target, you have to set > DESTDIR in xeno-config environment so that it outputs > -I/home/romain/target/usr/realtime/include and > -L/home/romain/target/usr/realtimeLib. > > Since it is a rather obscure functionality, it probably > deserves an explanation. Ok, done. Please apply patches #472 and #474: https://gna.org/patch/index.php?func=detailitem&item_id=472 https://gna.org/patch/index.php?func=detailitem&item_id=474 -- Romain Lenglet
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
> > > >I will look into making a xenomai.pc file. > > > > > > Make it a xenomai.pc.in file ;-) Yes, that's what I considered doing. > > I am not sure we want to depend on pkg-config... > > Gilles, put it the other way around. Xenomai won't depend on > pkg-config, but applications using Xenomai, will happily > depend on it, if they choose this option. To me, pkg-config > shouldn't be a replacement, but an alternative choice to > xeno-config. I agree, it considered that as an alternative. Unfortunately, it is not that simple. It would be necessary to create several *.pc.in files, one for each set of config parameters, cf. the output of xeno-config: - xenomai-kernel.pc.in <-> --kernel-* - xenomai-native.pc.in <-> --xeno-* - xenomai-posix.pc.in <-> --posix-* - xenomai-uvm.pc.in <-> --uvm-* Beware that me must "merge" the *-cflags and *-ldflags config info, because pkg-config splits them a-posteriori, cf. the --cflags, --libs-only-L and --libs-only-l options of pkg-config. That separation is different from that of Xenomai's xeno-config. And the xeno-config script would still be necessary for some parameters, such as: xeno-config --module-dir and: xeno-config --config pkg-config is too limited regarding the information that we can put into .pc files... Anyway, Stephane, if you want to write the four *.pc.in, go on please! :) -- Romain Lenglet ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
RE: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Gilles Chanteperdrix wrote: > > Romain Lenglet wrote: > > [..] > > >I found a better solution, that could be a replacement for both a > > >xenomai.m4 trick, and the xeno-config script: pkg-config. > > >http://pkgconfig.freedesktop.org/wiki/ > > >There are packages for pkgconfig in both Debian and RedHat, > > >AFAIK, and surely for all other distribs. > > > > > >I will look into making a xenomai.pc file. > > > > Make it a xenomai.pc.in file ;-) > > I am not sure we want to depend on pkg-config... Gilles, put it the other way around. Xenomai won't depend on pkg-config, but applications using Xenomai, will happily depend on it, if they choose this option. To me, pkg-config shouldn't be a replacement, but an alternative choice to xeno-config. -- Stephane ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
RE: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Fillod Stephane wrote: > Romain Lenglet wrote: > [..] > >I found a better solution, that could be a replacement for both a > >xenomai.m4 trick, and the xeno-config script: pkg-config. > >http://pkgconfig.freedesktop.org/wiki/ > >There are packages for pkgconfig in both Debian and RedHat, > >AFAIK, and surely for all other distribs. > > > >I will look into making a xenomai.pc file. > > Make it a xenomai.pc.in file ;-) I am not sure we want to depend on pkg-config... -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
RE: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote: [..] >I found a better solution, that could be a replacement for both a >xenomai.m4 trick, and the xeno-config script: pkg-config. >http://pkgconfig.freedesktop.org/wiki/ >There are packages for pkgconfig in both Debian and RedHat, >AFAIK, and surely for all other distribs. > >I will look into making a xenomai.pc file. Make it a xenomai.pc.in file ;-) -- Stephane ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
> > A simpler solution would be to ship a xenomai.m4 to be used > > as a acinclude.m4 in every project using Xenomai. But I > > have had very bad experiences with aclocal in that use > > case. aclocal is quite buggy. And it would be more > > confortable for projects it is were immediately available > > after installing Xenomai. > > Yes, this was the original plan, but there are still many > things on our todo list before that. I found a better solution, that could be a replacement for both a xenomai.m4 trick, and the xeno-config script: pkg-config. http://pkgconfig.freedesktop.org/wiki/ There are packages for pkgconfig in both Debian and RedHat, AFAIK, and surely for all other distribs. I will look into making a xenomai.pc file. > DESTDIR is used by xeno-config the same way it is used by > Makefiles. When you compiled Xenomai for a target and > installed it with DESTDIR=/home/romain/target, you have to set > DESTDIR in xeno-config environment so that it outputs > -I/home/romain/target/usr/realtime/include and > -L/home/romain/target/usr/realtimeLib. > > Since it is a rather obscure functionality, it probably > deserves an explanation. Ok, done. Please apply patches #472 and #474: https://gna.org/patch/index.php?func=detailitem&item_id=472 https://gna.org/patch/index.php?func=detailitem&item_id=474 -- Romain Lenglet ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote: > > In order to compare Xenomai with other Debian packagees, I > > checked gtk-config, and I have a few remarks on xeno-config > > and its manpage. > [...] > > I merely documented xeno-config as it is now, and made the > printed usage consistent. If you modify it, I will update the > manpage accordingly. Sorry for the digression then. But the point about DESTDIR still holds, from my point of view. > > > Another item to add to the looOOong-term wishlist: I would like > to have ready-to-use autoconf rules, to use instead of > xeno-config. > > If someone ever writes such rules, e.g. in a "xenomai.m4" file, > it would only be necessary, at Xenomai install time: > 1- to copy xenomai.m4 into /usr/share/autoconf/autoconf/ > 2- to add the following line into autoconf.m4: > m4_include([autoconf/xenomai.m4]) > 2- to regenerate autoconf.m4f by running: > cd /usr/share/autoconf/autoconf > autom4te --language=autoconf --freeze --output=autoconf.m4f > > A simpler solution would be to ship a xenomai.m4 to be used as a > acinclude.m4 in every project using Xenomai. But I have had very > bad experiences with aclocal in that use case. aclocal is quite > buggy. And it would be more confortable for projects it is were > immediately available after installing Xenomai. Yes, this was the original plan, but there are still many things on our todo list before that. > > > > Now, about the manpage itself, unless I am wrong, the DESTDIR > > feature is not documented, it is very useful when compiling > > for a target. > > DESTDIR is a feature of makefiles generated through Automake, not > of xeno-config. Why would you like to document this is in > xeno-config's manpage? DESTDIR is used by xeno-config the same way it is used by Makefiles. When you compiled Xenomai for a target and installed it with DESTDIR=/home/romain/target, you have to set DESTDIR in xeno-config environment so that it outputs -I/home/romain/target/usr/realtime/include and -L/home/romain/target/usr/realtimeLib. Since it is a rather obscure functionality, it probably deserves an explanation. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
> In order to compare Xenomai with other Debian packagees, I > checked gtk-config, and I have a few remarks on xeno-config > and its manpage. [...] I merely documented xeno-config as it is now, and made the printed usage consistent. If you modify it, I will update the manpage accordingly. Another item to add to the looOOong-term wishlist: I would like to have ready-to-use autoconf rules, to use instead of xeno-config. If someone ever writes such rules, e.g. in a "xenomai.m4" file, it would only be necessary, at Xenomai install time: 1- to copy xenomai.m4 into /usr/share/autoconf/autoconf/ 2- to add the following line into autoconf.m4: m4_include([autoconf/xenomai.m4]) 2- to regenerate autoconf.m4f by running: cd /usr/share/autoconf/autoconf autom4te --language=autoconf --freeze --output=autoconf.m4f A simpler solution would be to ship a xenomai.m4 to be used as a acinclude.m4 in every project using Xenomai. But I have had very bad experiences with aclocal in that use case. aclocal is quite buggy. And it would be more confortable for projects it is were immediately available after installing Xenomai. > Now, about the manpage itself, unless I am wrong, the DESTDIR > feature is not documented, it is very useful when compiling > for a target. DESTDIR is a feature of makefiles generated through Automake, not of xeno-config. Why would you like to document this is in xeno-config's manpage? -- Romain Lenglet
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote: > > In order to compare Xenomai with other Debian packagees, I > > checked gtk-config, and I have a few remarks on xeno-config > > and its manpage. > [...] > > I merely documented xeno-config as it is now, and made the > printed usage consistent. If you modify it, I will update the > manpage accordingly. Sorry for the digression then. But the point about DESTDIR still holds, from my point of view. > > > Another item to add to the looOOong-term wishlist: I would like > to have ready-to-use autoconf rules, to use instead of > xeno-config. > > If someone ever writes such rules, e.g. in a "xenomai.m4" file, > it would only be necessary, at Xenomai install time: > 1- to copy xenomai.m4 into /usr/share/autoconf/autoconf/ > 2- to add the following line into autoconf.m4: > m4_include([autoconf/xenomai.m4]) > 2- to regenerate autoconf.m4f by running: > cd /usr/share/autoconf/autoconf > autom4te --language=autoconf --freeze --output=autoconf.m4f > > A simpler solution would be to ship a xenomai.m4 to be used as a > acinclude.m4 in every project using Xenomai. But I have had very > bad experiences with aclocal in that use case. aclocal is quite > buggy. And it would be more confortable for projects it is were > immediately available after installing Xenomai. Yes, this was the original plan, but there are still many things on our todo list before that. > > > > Now, about the manpage itself, unless I am wrong, the DESTDIR > > feature is not documented, it is very useful when compiling > > for a target. > > DESTDIR is a feature of makefiles generated through Automake, not > of xeno-config. Why would you like to document this is in > xeno-config's manpage? DESTDIR is used by xeno-config the same way it is used by Makefiles. When you compiled Xenomai for a target and installed it with DESTDIR=/home/romain/target, you have to set DESTDIR in xeno-config environment so that it outputs -I/home/romain/target/usr/realtime/include and -L/home/romain/target/usr/realtimeLib. Since it is a rather obscure functionality, it probably deserves an explanation. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote: > > if you see an error, please provide a proper patch. > > Here is a patch that includes the correction of xeno-config.in > and the manpage. If someone wants to add it to the patch tracker > on the Gna! project page, please do it. You are supposed to be able to ad that patch to the tracker: being a logged-in user should be enough to be able to post a patch. I do not think it wise to open it to anonymous users, it would open it for use by spammers. > I am currently working on manpages for xeno-load(1) and > runinfo(5) (for the format of .runinfo files). I will send a > patch with these. Thanks. Note that you will need to document the latency test. This looks important, because this is the first program users should run, before messing with .runinfo. In order to compare Xenomai with other Debian packagees, I checked gtk-config, and I have a few remarks on xeno-config and its manpage. gtk-config is made to be sourced from configure scripts, so that configure scripts have a simple way to know whether GTK is installed, and a simple way to get the glib_* variables and export them to the generated makefiles. When run with no arguments, xeno-config prints the usage, but most importantly returns an error. I would suggest firstly that we do not print anything, after all the standard way to get help is the --help or -h argument, but if you do insist that you want help, I admit configure script may redirect output when sourcing xeno-config. But I strongly suggest we return 0, otherwise, there is no simple way for a configure script to know whether Xenomai is correctly installed. gtk-config has no --verbose option and I wonder how useful this option is. I mean, if you want to have the variables list, you may run (modulo we do not return 1 as status when called with no arguments) . xeno-config set | grep '^XENO' Now, about the manpage itself, unless I am wrong, the DESTDIR feature is not documented, it is very useful when compiling for a target. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
> In order to compare Xenomai with other Debian packagees, I > checked gtk-config, and I have a few remarks on xeno-config > and its manpage. [...] I merely documented xeno-config as it is now, and made the printed usage consistent. If you modify it, I will update the manpage accordingly. Another item to add to the looOOong-term wishlist: I would like to have ready-to-use autoconf rules, to use instead of xeno-config. If someone ever writes such rules, e.g. in a "xenomai.m4" file, it would only be necessary, at Xenomai install time: 1- to copy xenomai.m4 into /usr/share/autoconf/autoconf/ 2- to add the following line into autoconf.m4: m4_include([autoconf/xenomai.m4]) 2- to regenerate autoconf.m4f by running: cd /usr/share/autoconf/autoconf autom4te --language=autoconf --freeze --output=autoconf.m4f A simpler solution would be to ship a xenomai.m4 to be used as a acinclude.m4 in every project using Xenomai. But I have had very bad experiences with aclocal in that use case. aclocal is quite buggy. And it would be more confortable for projects it is were immediately available after installing Xenomai. > Now, about the manpage itself, unless I am wrong, the DESTDIR > feature is not documented, it is very useful when compiling > for a target. DESTDIR is a feature of makefiles generated through Automake, not of xeno-config. Why would you like to document this is in xeno-config's manpage? -- Romain Lenglet ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote: > > if you see an error, please provide a proper patch. > > Here is a patch that includes the correction of xeno-config.in > and the manpage. If someone wants to add it to the patch tracker > on the Gna! project page, please do it. You are supposed to be able to ad that patch to the tracker: being a logged-in user should be enough to be able to post a patch. I do not think it wise to open it to anonymous users, it would open it for use by spammers. > I am currently working on manpages for xeno-load(1) and > runinfo(5) (for the format of .runinfo files). I will send a > patch with these. Thanks. Note that you will need to document the latency test. This looks important, because this is the first program users should run, before messing with .runinfo. In order to compare Xenomai with other Debian packagees, I checked gtk-config, and I have a few remarks on xeno-config and its manpage. gtk-config is made to be sourced from configure scripts, so that configure scripts have a simple way to know whether GTK is installed, and a simple way to get the glib_* variables and export them to the generated makefiles. When run with no arguments, xeno-config prints the usage, but most importantly returns an error. I would suggest firstly that we do not print anything, after all the standard way to get help is the --help or -h argument, but if you do insist that you want help, I admit configure script may redirect output when sourcing xeno-config. But I strongly suggest we return 0, otherwise, there is no simple way for a configure script to know whether Xenomai is correctly installed. gtk-config has no --verbose option and I wonder how useful this option is. I mean, if you want to have the variables list, you may run (modulo we do not return 1 as status when called with no arguments) . xeno-config set | grep '^XENO' Now, about the manpage itself, unless I am wrong, the DESTDIR feature is not documented, it is very useful when compiling for a target. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote: > > if you see an error, please provide a proper patch. > > Here is a patch that includes the correction of xeno-config.in > and the manpage. If someone wants to add it to the patch tracker > on the Gna! project page, please do it. > > > I cannot see the error youve 'corrected' below.. > > You will see in the patch. ;) > The usage mentionned --module-cxxflags and --kernel-cxxflags that > are not allowed, and the actual set of accepted options is > larger than previously displayed in the usage. > > > In fact, youve added one; -v doesnt work, --v does. > > Thanks, corrected in this patch. Thanks a lot, will apply. I would move the man directory under the doc directory though. > If someone applies the patch to the repository, it will be > necessary to run autoreconf once (to regenerate configure and > man/GNUmakefile.in). It does not work on my system, apparently > because my versions of automake and autoconf are too recent, and > some rule files seem to not be included in the repository. The necessary versions of the autotools are the one in Debian Sarge, and their version is given in README.INSTALL: o autoconf 2.59 o automake 1.9.5 o aclocal 1.9.5 o libtool 1.5.6 If you want to regenerate the autotools files, you may enable the "maintainer mode" in Xenomai configuration or run script/bootstrap (you have to run it under the sim directory too). autoreconf does not work because it greps the flags to be passed to aclocal by looking for the ACLOCAL_AMFLAGS variable definition in the top Makefile, but there is no top Makefile in Xenomai, only a top GNUmakefile. I tracked down this issue and changed my autoreconf script a long time ago but am using the bootstrap script now... Automake maintainer mode, on the other hand, works fine with makefiles called GNUmakefile. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
> if you see an error, please provide a proper patch. Here is a patch that includes the correction of xeno-config.in and the manpage. If someone wants to add it to the patch tracker on the Gna! project page, please do it. > I cannot see the error youve 'corrected' below.. You will see in the patch. ;) The usage mentionned --module-cxxflags and --kernel-cxxflags that are not allowed, and the actual set of accepted options is larger than previously displayed in the usage. > In fact, youve added one; -v doesnt work, --v does. Thanks, corrected in this patch. If someone applies the patch to the repository, it will be necessary to run autoreconf once (to regenerate configure and man/GNUmakefile.in). It does not work on my system, apparently because my versions of automake and autoconf are too recent, and some rule files seem to not be included in the repository. I am currently working on manpages for xeno-load(1) and runinfo(5) (for the format of .runinfo files). I will send a patch with these. -- Romain Lenglet --- xenomai/GNUmakefile.am 2005-10-08 06:11:23.0 +0900 +++ xenomai-man/GNUmakefile.am 2005-10-18 01:44:09.813960500 +0900 @@ -12,7 +12,8 @@ scripts \ @XENO_MAYBE_DOCDIR@ \ $(subdirs) \ - config + config \ + man EXTRA_DIST = CREDITS makefile Kconfig README.INSTALL README.QUICKINSTALL TROUBLESHOOTING @XENO_MAYBE_SIMDIR@ --- xenomai/configure.in 2005-10-15 23:44:26.0 +0900 +++ xenomai-man/configure.in 2005-10-18 01:54:33.004907500 +0900 @@ -1474,6 +1474,7 @@ include/nucleus/asm-ppc64/GNUmakefile \ include/nucleus/asm-ia64/GNUmakefile \ include/nucleus/asm-uvm/GNUmakefile \ + man/GNUmakefile \ nucleus/GNUmakefile \ scripts/GNUmakefile \ scripts/xeno-config \ --- xenomai/man/GNUmakefile.am 1970-01-01 09:00:00.0 +0900 +++ xenomai-man/man/GNUmakefile.am 2005-10-18 01:43:50.464751250 +0900 @@ -0,0 +1,2 @@ +man1_MANS = xeno-config.man +dist_man1_MANS = $(man1_MANS) --- xenomai/man/xeno-config.man 1970-01-01 09:00:00.0 +0900 +++ xenomai-man/man/xeno-config.man 2005-10-18 02:04:16.497373500 +0900 @@ -0,0 +1,120 @@ +'\" t +.\" ** The above line should force tbl to be a preprocessor ** +.\" Man page for xeno-config +.\" +.\" Copyright (C) 2005 Romain Lenglet <[EMAIL PROTECTED]> +.\" +.\" You may distribute under the terms of the GNU General Public +.\" License as specified in the file COPYING that comes with the +.\" Xenomai distribution. +.\" +.pc +.TH XENO-CONFIG 1 "2005-10-17" "1.9.9" "Xenomai" +.SH NAME +xeno-config \- Display Xenomai libraries configuration +.SH SYNOPSIS +.\" The general command line +.B xeno-config +.br +\fBxeno-config\fP \fB\-\-v\fP | \fB\-\-verbose\fP +.br +.B xeno-config \-\-help +.br +\fBxeno-config\fP [\fB\-\-version\fP] [\fB\-\-cc\fP] [\fB\-\-cross\-compile\fP] [\fB\-\-arch\fP] [\fB\-\-subarch\fP] [\fB\-\-prefix\fP] [\fB\-\-config\fP] [\fB\-\-mod*\-cflags\fP|\fB\-\-module\-cflags\fP|\fB\-\-kernel\-cflags\fP] [\fB\-\-xeno\-cflags\fP|\fB\-\-fusion\-cflags\fP] [\fB\-\-xeno\-ldflags\fP|\fB\-\-fusion\-ldflags\fP] [\fB\-\-posix\-cflags\fP] [\fB\-\-posix\-ldflags\fP] [\fB\-\-uvm\-cflags\fP] [\fB\-\-uvm\-ldflags\fP] [\fB\-\-linux\-dir\fP|\fB\-\-linux\fP] [\fB\-\-linux\-ver*\fP|\fB\-\-linux\-version\fP] [\fB\-\-mod*\-dir\fP|\fB\-\-module\-dir\fP] [\fB\-\-sym*\-dir\fP|\fB\-\-symbol\-dir\fP] [\fB\-\-lib*\-dir\fP|\fB\-\-library\-dir\fP|\fB\-\-libdir\fP|\fB\-\-user\-libdir\fP] +.SH DESCRIPTION +\fBxeno-config\fP is a script that is used to to display the compiler and linker flags that are required for building applications that use Xenomai. +Any combination of options can be chosen (except \fB\-\-verbose\fP and \fB\-\-help\fP) to display configuration information, and options can be given in any order. +The command output one line for each option, in the same order as the options. + +When \fBxeno-config \-\-verbose\fP is executed, all configuration information is displayed in a different, human-readable format. + +When \fBxeno-config\fP is executed without any options, the output is equivalent to than when executing \fBxeno-config \-\-verbose\fP then \fBxeno-config \-\-help\fP. + +.\" +.SH OPTIONS +In an option's description, a \fB*\fP in the option name is meant as a wildcard. For instance, \fB\-\-mod\-cflags\fP, \fB\-\-modu\-cflags\fP and \fB\-\-modanything\-cflags\fP are all valid and synonymous options. +.TP +.B \-\-v, \-\-verbose +Outputs all configuration information, in a human-readable format. +.TP +.B \-\-help +Outputs the list of available command-line options. +.TP +.B \-\-version +Outputs one line with the installed Xenomai version. +.TP +.B \-\-cc +Outputs one line with the path to the C compiler command used to compiled Xenomai. +.TP +.B \-\-cross\-compile +Outputs one line with the name prefix of the commands used to compile Xenomai, in the case it was cross-compiled. +The ouput line is empty if it was not cross-compiled. +.TP +.B \-\-arch +
Re: [Xenomai-core] Cosmetic changes to script xeno-config + man page
Romain Lenglet wrote:
By the way, I noticed that the output of function usage() in that
script was wrong. Here is a correct version, to replace the one
if you see an error, please provide a proper patch.
I cannot see the error youve 'corrected' below..
In fact, youve added one; -v doesnt work, --v does.
in scripts/xeno-config.in:
usage ()
{
cat <
thx
jimc
