X.Org Foundation GSoC mentors and projects
Hi everyone, Thanks to the amazing work Rodrigo does mentoring students (which introduces them to GNU/Linux in general and X.Org/fd.o in particular) it looks like we might have some potential GSoC candidates this year. The last time we ran an X.Org GSoC, back in 2020, our amazing student, Melissa, not only passed her project with flying colours, she continues on in our community to this day as a co-admin of the VKMS driver. Several other members of our community came to us via GSoC and are also still with us making significant contributions. Rodrigo and Melissa have put together a project they are excited to mentor: https://www.x.org/wiki/AMDGPU2022/ . Daniel Vetter has also agreed to mentor; perhaps a drm-related project. I've agreed to be the admin on behalf of X.Org for our participation in GSoC. If anyone else is interested in volunteering we would certainly appreciate the help. We're always looking for mentors and project ideas. Our current list of projects/mentors is found on our Ideas page: https://www.x.org/wiki/SummerOfCodeIdeas/ If you have any questions or interest please get in touch! Best regards, Trevor
Re: [Mesa-dev] should we do GSoC 2021?
Hi Omar, On Wed 2021-02-10 @ 02:31:11 PM, Omar Emara wrote: > If applying to GSoC will not take much time from you, I think you should apply > regardless and leave the acceptance decision on a per-project basis. GSoC works, literally, the other way around. Unfortunately GSoC doesn't start with students expressing their interest, then organizations applying based on the student interest they receive. GSoC starts with mentors willing to volunteer to mentor, then organizations deciding to apply based on the level of interest expressed by potential volunteers, then google selecting which organizations can participate, then students expressing an interest. Without a proper task list XOrg will not be selected by Google to participate in GSoC. Google has always been clear that the task list is one of the most important criteria for deciding which organizations they pick to participate. Mentors need to update the task list with ideas they're willing to mentor. So far nobody has volunteered to mentor, and by extension, nobody has volunteered to update the tasks to fit into the new constraints Google is applying to GSoC 2021. Organization applications close Feb 19, if there are no mentors we can't possibly consider participating. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
should we do GSoC 2021?
Hi everyone, There are discussions regarding whether or not we want to participate in GSoC this year. Org applications are open now until Feb 19. Last year at the GSoC Mentor Summit (Oct 2020) it was announced that changes were coming to GSoC 2021: - the amount of time a student is expected to spend on a project is halved - stipends are halved - overall duration is shortened to 10 weeks - lowered eligibility requirements As a result, project expectations are supposed to be reduced as well. Whereas previously a student was expected to work 350 hours and had to be enrolled in an accredited university programme, now projects are expected to take a student 175 hours and accredited colleges and coding camps are acceptable. What this means right now is that our list of ideas ( https://www.x.org/wiki/SummerOfCodeIdeas/) needs to be checked to see if it's still suitable. Are the project ideas still valid? Are they something a student could do in 175 hours? Some people feel that 175 hours might not be enough time to contribute a significant coding effort against an fd.o project. At this point my gut feeling is to hold off on the application. If I can't find anyone to help go through the ideas list or who are willing to mentor under these new changes then we'll need to consider our options. Thoughts? Thanks so much for reading, best regards, Trevor ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
X.Org GSoC 2020 - call for project ideas and mentors
Hello! Once again X.Org has been fortunate to have been chosen to be part of GSoC! Starting March 16 (this Monday) students will be able to register and submit their applications for GSoC. If you can spare a moment, please take a look at our current "idea" page which help students to start thinking about potential project ideas: https://www.x.org/wiki/SummerOfCodeIdeas/ If you have any project ideas that might suit a post-secondary student, please add them to the list, or email me the details and I'll be happy to update the list on your behalf. Conversely, if there are projects on that list that are no longer relevant, please let me know and I'll take them down. Also, if you are considering being a mentor, please get in touch so I can add you to the list. If you have any thoughts or questions, please don't hesitate to get in touch. Best regards, Trevor ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: 2019 Xorg Election Results
On Wed, May 8, 2019 at 10:06 AM Harry Wentland wrote: > Trevor Woerner 4 14 10 10 8 19 199 > I'd like to truly thank the other 3 people who chose me as their 1st pick, and the 14 (:-O !!) who chose me as their first 2nd-place pick! Considering I'm not an active contributor of code to this project, I think this is an amazing result! Thank you :-D Although I didn't make it on the board, I remain committed to running GSoC and EVoC. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
X.Org GSoC 2019 - Student Application Period
I'm happy to announce that the X.Org Foundation has been chosen to participate in this year's GSoC program! Students have from now until April 9th to submit their proposals. Students will be looking at https://www.x.org/wiki/SummerOfCodeIdeas/ and https://www.x.org/wiki/ToDo/ for ideas. Please take a moment to review those lists to see: - are these valid ideas? - should items be removed? - are there items that can be added? Also, please consider signing up to mentor. All the student enthusiasm in the world can't be put to any use if there are no mentors. A mentor only needs to provide technical direction and grading, all other aspects of the program will be handled by myself. If you have any updates to the ideas pages or are interested in mentoring, please get in touch! Students: Application requirements: * Applicants meet Google's requirements for participation in Summer of Code. * Applicants are in regular and close contact with their X.Org mentors and the community (IRC, email) * Applicants know their target programming language. * Applicants must successfully upstream a simple patch to demonstrate they know the process. * Applicants are willing to blog weekly and interact with the community (failure to do so will result in a fail at the next review) Check out https://www.x.org/wiki/GSoCApplication/ for information about how to apply. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 1/5] autoconf: fix warning by replacing deprecated AC_HELP_STRING
On 01/07/14 15:19, Gaetan Nadon wrote: ...snip... This series builds fine on openSUSE 13.1, therefore Reviewed-by: Trevor Woerner trevor.woer...@linaro.org Maybe it'd be nice if there were a Built-by: or Builds-without-errors-by/on: :-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH video-s3] Remove mibstore.h
On 01/07/14 16:32, Gaetan Nadon wrote: As it was done in numerous other drivers. Fixes compile error. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- src/s3_driver.c |2 -- 1 file changed, 2 deletions(-) diff --git a/src/s3_driver.c b/src/s3_driver.c index 61242ad..85763ba 100644 --- a/src/s3_driver.c +++ b/src/s3_driver.c @@ -52,7 +52,6 @@ #include compiler.h #include mipointer.h #include micmap.h -#include mibstore.h #include fb.h #include inputstr.h #include shadowfb.h @@ -822,7 +821,6 @@ static Bool S3ScreenInit(SCREEN_INIT_ARGS_DECL) fbPictureInit (pScreen, 0, 0); S3DGAInit(pScreen); -miInitializeBackingStore(pScreen); xf86SetBackingStore(pScreen); /* framebuffer manager setup */ Tested-by: Trevor Woerner trevor.woer...@linaro.org ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:modular] build.sh: remove xf86-input-mouse from Linux
Hello Gaetan, On 01/05/14 19:19, Gaetan Nadon wrote: On 14-01-05 04:58 PM, Trevor Woerner wrote: Remove xf86-input-mouse from the list of modules to build for a Linux target since Linux uses xf86-input-evdev instead. Signed-off-by: Trevor Woerner trevor.woer...@linaro.org As long as it builds on Linux, it's fine. The primary reason for platform check is to prevent build breaks for people not familiar with X. It saves them time and saves us from receiving posts and bug reports. Majority of drivers are only useful on very specific hardware, like video cards, tablets and so on. Even so, only a fraction of the C code is not portable. The configuration, man pages or docs can be maintained on any platforms. Developers also need to know where code may break when they change ABI, so it is helpful to have more modules than less that builds on the platform where they work. I am aware this is only one of many perspectives. It is much easier to remove a module from the list than hunting down for missing modules. I also do not think build.sh helps anyone make a decision as to which module should be include in the project they are working on. Thank you for this explanation. I agree with everything you've said, so I have no issues with leaving xf86-input-mouse in the list of modules which are built on a Linux host. A couple days ago I took the list of projects available on fd.o, sorted them by their last change, and noticed there are a number of them missing from the list of modules built by build.sh which appear to still be active projects. For example: mesa/glu, mesa/glut, mesa/demos, mesa/mesa-test, cairo, and a bunch of others (I haven't finished yet). Do you think it would be worth my time to submit a patch to add some of these active projects into the list of modules built by build.sh? Best regards, Trevor ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:xf86-input-mouse] Use asprintf (or Xprintf on old servers) instead of strdup+sprintf
On 01/05/14 13:10, Alan Coopersmith wrote: On 01/ 4/14 11:35 AM, Patrik Jakobsson wrote: asprintf needs _GNU_SOURCE to be defined or you'll get an implicit declaration and build failure. I fixed it with: Only on Linux, and you should be using xf86-input-evdev there, not -mouse. Any idea which OSes still use -mouse? Everything but Linux? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH:modular] build.sh: remove xf86-input-mouse from Linux
Remove xf86-input-mouse from the list of modules to build for a Linux target
since Linux uses xf86-input-evdev instead.
Signed-off-by: Trevor Woerner trevor.woer...@linaro.org
---
build.sh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/build.sh b/build.sh
index 3500a70..d606983 100755
--- a/build.sh
+++ b/build.sh
@@ -1175,11 +1175,11 @@ build_all_modules() {
;;
*)
build driver xf86-input-keyboard
- build driver xf86-input-mouse
build driver xf86-input-synaptics
build driver xf86-input-void
case $HOST_OS in
FreeBSD)
+ build driver xf86-input-mouse
case $HOST_CPU in
sparc64)
build driver xf86-video-sunffb
@@ -1187,6 +1187,7 @@ build_all_modules() {
esac
;;
NetBSD | OpenBSD)
+ build driver xf86-input-mouse
build driver xf86-video-wsfb
build driver xf86-video-sunffb
;;
@@ -1205,6 +1206,7 @@ build_all_modules() {
esac
case $HOST_CPU in
sparc | sparc64)
+ build driver xf86-input-mouse
build driver xf86-video-suncg14
build driver xf86-video-suncg3
build driver xf86-video-suncg6
--
1.8.5.2.227.g53f3478
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular] build.sh: use 'make' semantics to keep going
From: Trevor Woerner twoer...@gmail.com
This build script has used the '-n' (or NO QUIT) option to convey that
the user wants the build to continue as much as possible even though an
individual module might fail to build. The 'make' utility refers to this
as KEEP GOING and uses the '-k|--keep-going' parameter.
I think it would be better for our script to use a notion with which
developers are most likely to already be familiar to request this same
behaviour.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
build.sh | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/build.sh b/build.sh
index a3eaf77..7afc948 100755
--- a/build.sh
+++ b/build.sh
@@ -540,7 +540,7 @@ process() {
}
# process each module/component and handle:
-# LISTONLY, RESUME, NOQUIT, and BUILD_ONE
+# LISTONLY, RESUME, KEEPGOING, and BUILD_ONE
# arguments:
# $1 - module
# $2 - component
@@ -579,7 +579,7 @@ build() {
if [ $process_rtn -ne 0 ]; then
echo build.sh: error processing module/component:
\$module/$component\
- if [ X$NOQUIT = X ]; then
+ if [ X$KEEPGOING = X ]; then
exit 1
fi
return $process_rtn
@@ -1053,7 +1053,8 @@ usage() {
echo -d Run make distcheck in addition \all install\
echo -g Compile and link with debug information
echo -h, --help Display this help and exit successfully
-echo -n Do not quit after error; just print error message
+echo -k, --keep-going
+echo Continue with the build as much as possible despite
errors
echo -o module/component
echo Build just this module/component
echo -p Update source code before building (git pull --rebase)
@@ -1198,8 +1199,8 @@ do
-L)
LISTONLY=1
;;
--n)
- NOQUIT=1
+-k|--keep-going)
+ KEEPGOING=1
;;
-o)
if [ -n $BUILT_MODULES_FILE ]; then
--
1.7.9
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
anongit down?
Just wondering if I missed an announcement somewhere but I haven't been able to access anongit.freedesktop.org for the last couple hours. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v3 modular] build.sh: better integrate --autoresume and -n
On Tue, Jan 31, 2012 at 3:09 PM, Gaetan Nadon mems...@videotron.ca wrote: A couple of minor problems. I wouldn't rock the code too much as we can live with them. I am prepared to accept the patch as it is. Excellent, thanks for the review and testing :-) If autoresume reaches the last module in the autoresume file, it will get built anyway, whether it has previously passed or failed. It was coded that way on purpose to preserve the existing behaviour of --autoresume (it always assumes the last module in the built list failed), but I admit even I found it weird (no matter how the last module did it always has an implicit FAIL: status, but I didn't think you'd approve if the behaviour changed). The fix for this would entail figuring out if there is a next module to build and finding out what that next module might be. That isn't an easy thing to do. It is easier when a --modfile is provided, but only slightly so. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular] build.sh: remove xgi driver
From: Trevor Woerner twoer...@gmail.com
This driver was removed from xorg.modules in commit
ee55165c87833ffb4f73e3984158576ff7e0df58 with the
following commit message:
This hasn't been usable for multiple years and obviously nobody
cares about fixing it, so remove it from the default set, so
the tinderbox stops reporting it as a failure.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
build.sh |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/build.sh b/build.sh
index 9068f29..b5cc2cc 100755
--- a/build.sh
+++ b/build.sh
@@ -906,7 +906,6 @@ build_driver_video() {
build driver xf86-video-vesa
build driver xf86-video-vmware
build driver xf86-video-voodoo
-build driver xf86-video-xgi
}
# The server must be built before the drivers
--
1.7.6.233.gd79bc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular] build.sh: better integrate --autoresume and -n
From: Trevor Woerner twoer...@gmail.com
The --autoresume file option allows a user to specify a file into which
the build prints each module/component it has built. When a subsequent build
is restarted with file, the build can skip all previously built modules,
start with the last one (which is assumed to have failed previously), and
continue on.
The -n option allows a build to continue with subsequent modules even if
one or more of the modules fails to build correctly.
With this change, in addition to updating the --autoresume file with the
name of the module/component just built, file is also updated with the
status of the build. Therefore if you use -n you will have an --autoresume
file which lists the build status of all the modules you wanted to build.
A subsequent build using the --autoresume file will scan file looking
for failures and attempt to build them before continuing on with the build
from the end of the list.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
build.sh | 94 ++
1 files changed, 82 insertions(+), 12 deletions(-)
diff --git a/build.sh b/build.sh
index b5cc2cc..d5a0753 100755
--- a/build.sh
+++ b/build.sh
@@ -407,9 +407,6 @@ process() {
failed $GITCMD $module $component
return 1
fi
- if [ X$BUILT_MODULES_FILE != X ]; then
- echo $module/$component $BUILT_MODULES_FILE
- fi
return 0
fi
@@ -478,9 +475,6 @@ process() {
failed $MAKE $MAKEFLAGS $MAKECMD $module $component
return 1
fi
- if [ X$BUILT_MODULES_FILE != X ]; then
- echo $module/$component $BUILT_MODULES_FILE
- fi
return 0
fi
@@ -542,10 +536,6 @@ process() {
cd ${old_pwd}
-if [ X$BUILT_MODULES_FILE != X ]; then
- echo $module/$component $BUILT_MODULES_FILE
-fi
-
return 0
}
@@ -578,7 +568,16 @@ build() {
fi
process $module $component $confopts
-if [ $? -ne 0 ]; then
+process_rtn=$?
+if [ X$BUILT_MODULES_FILE != X ]; then
+ if [ $process_rtn -ne 0 ]; then
+ echo FAIL: $module/$component $BUILT_MODULES_FILE
+ else
+ echo PASS: $module/$component $BUILT_MODULES_FILE
+ fi
+fi
+
+if [ $process_rtn -ne 0 ]; then
echo build.sh: error processing module/component:
\$module/$component\
if [ X$NOQUIT = X ]; then
exit 1
@@ -1219,7 +1218,6 @@ do
required_arg $1 $2
shift
BUILT_MODULES_FILE=$1
- [ -f $1 ] RESUME=`tail -n 1 $1`
;;
--check)
CHECK=1
@@ -1308,6 +1306,78 @@ if [ X$LISTONLY = X ]; then
date
fi
+# if there is a BUILT_MODULES_FILE
+# then start off by checking for and trying to build any modules which failed
+# and aren't the last line
+if [ X$BUILT_MODULES_FILE != X -a -r $BUILT_MODULES_FILE ]; then
+built_lines=`cat $BUILT_MODULES_FILE | wc -l`
+built_lines_m1=`expr $built_lines - 1`
+orig_BUILT_MODULES_FILE=$BUILT_MODULES_FILE
+unset BUILT_MODULES_FILE
+curline=1
+while read line; do
+ built_status=`echo $line | cut -c-6`
+ if [ X$built_status = XFAIL: ]; then
+ line=`echo $line | cut -c7-`
+ module=`echo $line | cut -d' ' -f1 | cut -d'/' -f1`
+ component=`echo $line | cut -d' ' -f1 | cut -d'/' -f2`
+ confopts_check=`echo $line | cut -d' ' -f2-`
+ if [ $module/$component = $confopts_check ]; then
+ confopts=
+ else
+ confopts=$confopts_check
+ fi
+
+ build_ret=
+
+ # quick check for the module in $MODFILE (if present)
+ if [ X$MODFILE = X ]; then
+ build $module $component $confopts
+ if [ $? -eq 0 ]; then
+ build_ret=PASS
+ fi
+ else
+ cat $MODFILE | grep $module/$component /dev/null
+ if [ $? -eq 0 ]; then
+ build $module $component $confopts
+ if [ $? -eq 0 ]; then
+ build_ret=PASS
+ fi
+ fi
+ fi
+
+ if [ X$build_ret = XPASS ]; then
+ built_temp=`mktemp`
+ if [ $? -ne 0 ]; then
+ echo can't create tmp file, $orig_BUILT_MODULES_FILE not
modified
+ else
+ head -n `expr $curline - 1` $orig_BUILT_MODULES_FILE
$built_temp
+ echo PASS: $module/$component $built_temp
+ tail -n `expr $built_lines - $curline`
$orig_BUILT_MODULES_FILE $built_temp
+ mv $built_temp $orig_BUILT_MODULES_FILE
+ fi
+ fi
+ fi
+ if [ $curline -eq $built_lines_m1 ]; then
+ break
+ fi
+ curline=`expr $curline + 1`
+done $orig_BUILT_MODULES_FILE
+
+BUILT_MODULES_FILE
Re: [PATCH modular] build.sh: better integrate --autoresume and -n
Sorry, please ignore. I just noticed a case it doesn't correctly handle. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH v2 modular] build.sh: better integrate --autoresume and -n
From: Trevor Woerner twoer...@gmail.com
The --autoresume file option allows a user to specify a file into which
the build prints each module/component it has built. When a subsequent build
is restarted with file, the build can skip all previously built modules,
start with the last one (which is assumed to have failed previously), and
continue on.
The -n option allows a build to continue with subsequent modules even if
one or more of the modules fails to build correctly.
With this change, in addition to updating the --autoresume file with the
name of the module/component just built, file is also updated with the
status of the build. Therefore if you use -n you will have an --autoresume
file which lists the build status of all the modules you wanted to build.
A subsequent build using the --autoresume file will scan file looking
for failures and attempt to build them before continuing on with the build
from the end of the list.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
build.sh | 95 ++
1 files changed, 83 insertions(+), 12 deletions(-)
diff --git a/build.sh b/build.sh
index b5cc2cc..c754329 100755
--- a/build.sh
+++ b/build.sh
@@ -407,9 +407,6 @@ process() {
failed $GITCMD $module $component
return 1
fi
- if [ X$BUILT_MODULES_FILE != X ]; then
- echo $module/$component $BUILT_MODULES_FILE
- fi
return 0
fi
@@ -478,9 +475,6 @@ process() {
failed $MAKE $MAKEFLAGS $MAKECMD $module $component
return 1
fi
- if [ X$BUILT_MODULES_FILE != X ]; then
- echo $module/$component $BUILT_MODULES_FILE
- fi
return 0
fi
@@ -542,10 +536,6 @@ process() {
cd ${old_pwd}
-if [ X$BUILT_MODULES_FILE != X ]; then
- echo $module/$component $BUILT_MODULES_FILE
-fi
-
return 0
}
@@ -578,11 +568,21 @@ build() {
fi
process $module $component $confopts
-if [ $? -ne 0 ]; then
+process_rtn=$?
+if [ X$BUILT_MODULES_FILE != X ]; then
+ if [ $process_rtn -ne 0 ]; then
+ echo FAIL: $module/$component $BUILT_MODULES_FILE
+ else
+ echo PASS: $module/$component $BUILT_MODULES_FILE
+ fi
+fi
+
+if [ $process_rtn -ne 0 ]; then
echo build.sh: error processing module/component:
\$module/$component\
if [ X$NOQUIT = X ]; then
exit 1
fi
+ return $process_rtn
fi
if [ X$BUILD_ONE != X ]; then
@@ -1219,7 +1219,6 @@ do
required_arg $1 $2
shift
BUILT_MODULES_FILE=$1
- [ -f $1 ] RESUME=`tail -n 1 $1`
;;
--check)
CHECK=1
@@ -1308,6 +1307,78 @@ if [ X$LISTONLY = X ]; then
date
fi
+# if there is a BUILT_MODULES_FILE
+# then start off by checking for and trying to build any modules which failed
+# and aren't the last line
+if [ X$BUILT_MODULES_FILE != X -a -r $BUILT_MODULES_FILE ]; then
+built_lines=`cat $BUILT_MODULES_FILE | wc -l`
+built_lines_m1=`expr $built_lines - 1`
+orig_BUILT_MODULES_FILE=$BUILT_MODULES_FILE
+unset BUILT_MODULES_FILE
+curline=1
+while read line; do
+ built_status=`echo $line | cut -c-6`
+ if [ X$built_status = XFAIL: ]; then
+ line=`echo $line | cut -c7-`
+ module=`echo $line | cut -d' ' -f1 | cut -d'/' -f1`
+ component=`echo $line | cut -d' ' -f1 | cut -d'/' -f2`
+ confopts_check=`echo $line | cut -d' ' -f2-`
+ if [ $module/$component = $confopts_check ]; then
+ confopts=
+ else
+ confopts=$confopts_check
+ fi
+
+ build_ret=
+
+ # quick check for the module in $MODFILE (if present)
+ if [ X$MODFILE = X ]; then
+ build $module $component $confopts
+ if [ $? -eq 0 ]; then
+ build_ret=PASS
+ fi
+ else
+ cat $MODFILE | grep $module/$component /dev/null
+ if [ $? -eq 0 ]; then
+ build $module $component $confopts
+ if [ $? -eq 0 ]; then
+ build_ret=PASS
+ fi
+ fi
+ fi
+
+ if [ X$build_ret = XPASS ]; then
+ built_temp=`mktemp`
+ if [ $? -ne 0 ]; then
+ echo can't create tmp file, $orig_BUILT_MODULES_FILE not
modified
+ else
+ head -n `expr $curline - 1` $orig_BUILT_MODULES_FILE
$built_temp
+ echo PASS: $module/$component $built_temp
+ tail -n `expr $built_lines - $curline`
$orig_BUILT_MODULES_FILE $built_temp
+ mv $built_temp $orig_BUILT_MODULES_FILE
+ fi
+ fi
+ fi
+ if [ $curline -eq $built_lines_m1 ]; then
+ break
+ fi
+ curline=`expr $curline + 1
[PATCH modular] Format cleanup of help output
From: Trevor Woerner twoer...@gmail.com
Miscellaneous cleanups of the help text that is printed.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
build.sh | 31 +++
1 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/build.sh b/build.sh
index 5878ef1..9068f29 100755
--- a/build.sh
+++ b/build.sh
@@ -20,7 +20,8 @@ Environment variables specific to build.sh:
Each module/components is invoked with --datadir
LIBDIR Install object code libraries [EPREFIX/lib]
Each module/components is invoked with --libdir
- LOCALSTATEDIR Modifiable single-machine data [PREFIX/var]
+ LOCALSTATEDIR
+ Modifiable single-machine data [PREFIX/var]
Each module/components is invoked with --localstatedir
QUIET Do not print messages saying which checks are being made
Each module/components is invoked with --quite
@@ -33,7 +34,7 @@ Environment variables defined by the GNU Build System:
ACLOCAL The aclocal cmd name [aclocal -I \${DESTDIR}/\${DATADIR}/aclocal]
DESTDIR Path to the staging area where installed objects are relocated
MAKEThe name of the make command [make]
- MAKEFLAGS: Options to pass to all \$(MAKE) invocations
+ MAKEFLAGS Options to pass to all \$(MAKE) invocations
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -Llib dir if you have libraries in a
@@ -47,13 +48,15 @@ Environment variables defined by the shell:
\$DESTDIR/\$BINDIR is prepended
Environment variables defined by the dynamic linker:
- LD_LIBRARY_PATH List directories that the linker searches for shared objects
- \$DESTDIR/\$LIBDIR is prepended
+ LD_LIBRARY_PATH
+ List directories that the linker searches for shared objects
+ \$DESTDIR/\$LIBDIR is prepended
Environment variables defined by the pkg-config system:
- PKG_CONFIG_PATH List directories that pkg-config searches for libraries
- \$DESTDIR/\$DATADIR/pkgconfig and
- \$DESTDIR/\$LIBDIR/pkgconfig are prepended
+ PKG_CONFIG_PATH
+ List directories that pkg-config searches for libraries
+ \$DESTDIR/\$DATADIR/pkgconfig and
+ \$DESTDIR/\$LIBDIR/pkgconfig are prepended
EOF
}
@@ -1052,22 +1055,26 @@ usage() {
echo -g Compile and link with debug information
echo -h, --help Display this help and exit successfully
echo -n Do not quit after error; just print error message
-echo -o module/component Build just this module/component
+echo -o module/component
+echo Build just this module/component
echo -p Update source code before building (git pull --rebase)
echo -s sudo The command name providing superuser privilege
-echo --autoresume file Append module being built to, and autoresume
from, file
+echo --autoresume file
+echo Append module being built to, and autoresume from,
file
echo --check Run make check in addition \all install\
echo --clone Clone non-existing repositories (uses \$GITROOT if
set)
echo --cmd cmd Execute arbitrary git, gmake, or make command cmd
-echo --confflags options Pass options to autgen.sh/configure of all
modules
-echo --modfile file Only process the module/components specified in
file
+echo --confflags options
+echo Pass options to autgen.sh/configure of all modules
+echo --modfile file
+echo Only process the module/components specified in file
echo Any text after, and on the same line as, the
module/component
echo is assumed to be configuration options for the
configuration
echo of each module/component specifically
echo --retry-v1 Remake 'all' on failure with Automake silent rules
disabled
echo
echo Usage: $basename -L
-echo -L : just list modules to build
+echo -L Just list modules to build
echo
envoptions
}
--
1.7.6.233.gd79bc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] renamed: build.sh - xorg-build
Hi Walter, Thanks for your review. On Wed, Jan 25, 2012 at 3:15 AM, walter harms wha...@bfs.de wrote: would you mind to drop a line or two why this is needed ? I don't think anybody implied or said that this is a *needed* change, so I wouldn't want to defend a position that was never taken nor implied. Instead of started a potentially long, meandering thread about whether or not a rename would be nice, I started instead with the patch, but I never meant to imply I thought this was something that was needed. - build.sh is rather generic - most people are dropping (or never liked) the .sh at the end of scripts - most executables from this project start with either x or xorg This project appears to be in a bit of a cleanup mode (e.g. let's consider and apply a coding style) so I thought it would be a good time to consider a rename of this script. If you're not in favour of this change would it be because of the timing, or would you never be in favour of this change? Best regards, Trevor ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Per-component configure options
Hi Gaetan,
Thanks for reviewing my patch!
On Wed, Jan 18, 2012 at 7:49 PM, Gaetan Nadon mems...@videotron.ca wrote:
On 12-01-16 06:22 PM, Trevor Woerner wrote:
@@ -1009,9 +1017,15 @@ process_module_file() {
continue
fi
- module=`echo $line | cut -d'/' -f1`
- component=`echo $line | cut -d'/' -f2`
- build $module $component
+ module=`echo $line | cut -d' ' -f1 | cut -d'/' -f1`
+ component=`echo $line | cut -d' ' -f1 | cut -d'/' -f2`
+ confopts_check=`echo $line | cut -d' ' -f2-`
What is the role of the dash following f2? There were none before.
Each line of the modfile is assumed to contain a
module/component group, then an optional space, then an optional
space separated list of zero or more configure arguments.
module/component[ arg1[ arg2[ arg3...]]]
The first 2 cut lines grab the first item on the line (given a ' '
(space) separator) and further filter out the module and component
(given a '/' separator). The third cut line starts after the
module/component (optional space) and grabs everything else on the
line. Although my example (in a previous email) only demonstrates
giving one configure argument to mesa/drm, I tested this patch by
providing a range of different numbers of configuration arguments
(including zero) to various modules.
This cutting scheme revolves around the assumption the module and
component are always separated by a forward slash, even in the 2
cases where there is no component (i.e. pixman/ and xserver/. But
this is already the case. The existing build.sh already does this when
it provides the -L list. The use is just expected to maintain this
convention.
The reason there was no dash before is that there was only one cut
operation before (for the mod/comp) and now there are two. The
second cut takes everything after and including the second
space-separated group, thus the dash is required.
+ if [ $module/$component = $confopts_check ]; then
+ confopts=
+ else
+ confopts=$confopts_check
+ fi
+ build $module $component $confopts
done $MODFILE
Are all the new quotes around $component required? There can be no
spaces in the lines, e.g. app/xclock. The seperator is a space and a
'/'. Many double quotes have been added throughout the script.
Yes, the double quotes are required and were added as a result of
testing. They're needed in the 2 cases where there is no component
(i.e. pixman/ and xserver/) otherwise the $confopts becomes the 2nd
argument to the build (etc) routine. The blank second argument needs
to be preserved and is done so by the use of the quotes.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH v2 modular] Per-component configure options
From: Trevor Woerner twoer...@gmail.com
Allow a user to specify per-component configure options by
providing them in the --modfile file. Any text remaining on
a line following a given module/component is assumed to be
options which will be passed to the configuration script.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
build.sh | 35 ++-
1 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/build.sh b/build.sh
index 29bdd17..94202c2 100755
--- a/build.sh
+++ b/build.sh
@@ -150,11 +150,13 @@ failed() {
# arguments:
# $1 - module
# $2 - component
+# $3 - configuration options
# returns:
# (irrelevant)
module_title() {
module=$1
component=$2
+confopts=$3
# preconds
if [ X$module = X ]; then
return
@@ -163,6 +165,7 @@ module_title() {
echo
echo
==
echo == Processing module/component: \$module/$component\
+echo ==configuration options: $CONFFLAGS $confopts
}
checkfortars() {
@@ -343,7 +346,8 @@ clone() {
# perform processing of each module/component
# arguments:
# $1 - module
-# $2 - component (optional)
+# $2 - component
+# $3 - configure options
# returns:
# 0 - good
# 1 - bad
@@ -352,13 +356,14 @@ process() {
module=$1
component=$2
+confopts=$3
# preconds
if [ X$module = X ]; then
echo process() required first argument is missing
return 1
fi
-module_title $module $component
+module_title $module $component $confopts
SRCDIR=
CONFCMD=
@@ -448,7 +453,7 @@ process() {
${LIBDIR_USER:+--libdir=$LIBDIR} \
${LOCALSTATEDIR_USER:+--localstatedir=$LOCALSTATEDIR} \
${QUIET:+--quiet} \
- ${CONFFLAGS} \
+ ${CONFFLAGS} $confopts \
${CC:+CC=$CC} \
${CPP:+CPP=$CPP} \
${CPPFLAGS:+CPPFLAGS=$CPPFLAGS} \
@@ -538,13 +543,15 @@ process() {
# LISTONLY, RESUME, NOQUIT, and BUILD_ONE
# arguments:
# $1 - module
-# $2 - component (optional)
+# $2 - component
+# $3 - configure options
# returns:
# 0 - good
# 1 - bad
build() {
module=$1
component=$2
+confopts=$3
if [ X$LISTONLY != X ]; then
echo $module/$component
return 0
@@ -560,7 +567,7 @@ build() {
fi
fi
-process $module $component
+process $module $component $confopts
if [ $? -ne 0 ]; then
echo build.sh: error processing module/component:
\$module/$component\
if [ X$NOQUIT = X ]; then
@@ -982,6 +989,7 @@ build_doc() {
# (prerequisites and ordering are the responsibility of the user)
# globals used:
# $MODFILE - readable file containing list of modules to process
+# and their optional configuration options
# arguments:
# (none)
# returns:
@@ -1011,9 +1019,15 @@ process_module_file() {
continue
fi
- module=`echo $line | cut -d'/' -f1`
- component=`echo $line | cut -d'/' -f2`
- build $module $component
+ module=`echo $line | cut -d' ' -f1 | cut -d'/' -f1`
+ component=`echo $line | cut -d' ' -f1 | cut -d'/' -f2`
+ confopts_check=`echo $line | cut -d' ' -f2-`
+ if [ $module/$component = $confopts_check ]; then
+ confopts=
+ else
+ confopts=$confopts_check
+ fi
+ build $module $component $confopts
done $MODFILE
return 0
@@ -1038,8 +1052,11 @@ usage() {
echo --check Run make check in addition \all install\
echo --clone Clone non-existing repositories (uses \$GITROOT if
set)
echo --cmd cmd Execute arbitrary git, gmake, or make command cmd
-echo --confflags options Pass options to autgen.sh/configure
+echo --confflags options Pass options to autgen.sh/configure of all
modules
echo --modfile file Only process the module/components specified in
file
+echo Any text after, and on the same line as, the
module/component
+echo is assumed to be configuration options for the
configuration
+echo of each module/component specifically
echo --retry-v1 Remake 'all' on failure with Automake silent rules
disabled
echo
echo Usage: $basename -L
--
1.7.6.233.gd79bc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1.12] A coding style for the server
On Tue, Jan 17, 2012 at 10:02 PM, Daniel Stone dan...@fooishbar.org wrote: indent -linux -bad -bap -blf -bli0 -br -brs -cbi0 -cdw -nce -cs -i4 -hnl -l80 -lc80 -lp -nbbo -nbc -nbfda -nprs -npcs -npsl -saf -sai -saw -nut About a dozen of the options you specify are already included in the -linux option. As such your list only needs to include: -linux -bad -blf -bli0 -cbi0 -cdw -nce -cs -i4 -lc80 -nbbo -nbc -nbfda -nut In other words the following are already included in -linux: -bap -br -brs -hnl -l80 -lp -nprs -npcs -npsl -saf -sai -saw From reading the man page it appears the -nbbo (no break after boolean) option conflicts with the -hnl (honour newlines) option such that -hnl cancels -nbbo, therefore -nbbo is ignored. Personally I don't like it when a developer submits a patch that intermixes code changes with formatting changes. As such I'm not fond of the -lp (continue at parenthesis) option because it has the side-effect of encouraging this behaviour. If, for example, a given function has 5 arguments and the code is refactored to change the name of the function such that the new name is a different length from the previous name, the patch will then contain the changed line plus 4 lines of formatting changes to keep the arguments lined up. You mentioned that cuddling the else slightly outnumbered not cuddling (was there a vote that I missed, or are you basing this on an examination of the existing code?). However you then provide the -nce (don't cuddle else) option. Personally I prefer -nce, but if you'd like to go with the majority then -ce should be used instead. Best regards, Trevor ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1.12] A coding style for the server
On Tue, Jan 17, 2012 at 10:02 PM, Daniel Stone dan...@fooishbar.org wrote: I honestly -- honestly[0] -- don't care what the coding style is. I just care that we have one. PS I forgot to add that I agree with this statement 100% and think this is a good conversation to be having during the lull. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Per-component configure options
I'm surprised nobody seems interested in this patch, I would have thought a general mechanism to provide per-component configuration options would have been a feature for which people would have been waiting; especially the distribution maintainers. I was trying to perform a build from the git repositories on a clean installation of a Ubuntu 10.04.3 (LTS) machine and found that I couldn't build mesa/mesa successfully without supplying the --enable-nouveau-experimental-api configuration option when building mesa/drm. On my openSuSE 12.1 machine (which I normally use) the build of mesa/mesa gets contaminated by the system headers (which I hadn't noticed at the time) which are provided by the libdrm-devel package. The Ubuntu 10.04.3 machine doesn't have this header in /usr/include so the build fails. In any case a git build shouldn't be contaminated in this way. Ideally it would be great to perform a sysroot-style build at some point to find out what other modules are being contaminated by system include files, but that will have to wait until I find the motivation and/or time. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Per-component configure options
Thanks for the review Gaetan! I had completely forgot about the CONFFLAGS option. I'll start again and integrate the two (or could this be considered a replacement?). I'll also provide more usage documentation. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Per-component configure options
Hi Alan, Thanks for the review. (Please note that I'm purposefully being overly descriptive to help others on the list who might be new to the build.sh script) On Wed, Jan 18, 2012 at 4:09 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: However, I wasn't quite clear on how to use it - perhaps because I've failed to pay attention long enough that I didn't remember what the --modfile file referred to (nor have I had time to look into this patch really, given other priorities recently eating most of my time). By default build.sh will run through its internal list of all the modules of which it is aware and build all of them in the correct dependency order. Currently that list contains 246 modules on a Linux x86-ish machine. If you only want to build one specific module you can specify it with the -o option. But if you want to build a random subset of all the modules (which we assume is a common enough occurrence) it's best to provide a --modfile modfile option. Currently modfile is a plain text file which contains a list of each module you want built, one per line. At the time I was implementing the --modfile option we had discussed whether or not build.sh should be smart enough to sort the items in modfile itself based on its internal notion of the correct dependency order, but it was decided that if a user were using the --modfile option they would be confused if build.sh built the modules in an order different than the order specified in the modfile. Therefore build.sh builds the modules specified in modfile in the given order. To help a user create a modfile build.sh provides an -L option; if you run build.sh -L it will print an in-build-dependency-order list of all the modules of which it is aware (based on the machine's architecture). This output can be a good place to start for creating a custom modfile. With this patch I'm proposing an extension to the --modfile mechanism such that each line of the file still lists each of the modules you want built, but any remaining text on a given line (after a space) lists the options you would like passed to that module's configuration. So whereas previously my mofile looked like this: ... lib/libXxf86vm lib/libpciaccess pixman/ mesa/drm mesa/mesa data/bitmaps app/appres ... It now looks like this: ... lib/libXxf86vm lib/libpciaccess pixman/ mesa/drm --enable-nouveau-experimental-api mesa/mesa data/bitmaps app/appres ... I'm curious to know what you are using as your custom build infrastructure (if you are at liberty to say). Best regards, Trevor ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1.12] A coding style for the server
The biggest (only?) downside is that any one-shot an/or on-going reformatting of _existing_ code confounds future git-annotate and git-bisect :-( ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular] Per-component configure options
From: Trevor Woerner twoer...@gmail.com
Allow a user to specify per-component configure options by
providing them in the --modfile file. Any text remaining on
a line following a given module/component is assumed to be
options which will be passed to the configuration script.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
build.sh | 40 +++-
1 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/build.sh b/build.sh
index b01d652..5c34eb7 100755
--- a/build.sh
+++ b/build.sh
@@ -148,11 +148,13 @@ failed() {
# arguments:
# $1 - module
# $2 - component
+# $3 - configuration options
# returns:
# (irrelevant)
module_title() {
module=$1
component=$2
+confopts=$3
# preconds
if [ X$module = X ]; then
return
@@ -161,6 +163,7 @@ module_title() {
echo
echo
==
echo == Processing module/component: \$module/$component\
+echo ==configuration options: \$confopts\
}
checkfortars() {
@@ -341,7 +344,8 @@ clone() {
# perform processing of each module/component
# arguments:
# $1 - module
-# $2 - component (optional)
+# $2 - component
+# $3 - configure options
# returns:
# 0 - good
# 1 - bad
@@ -349,29 +353,30 @@ process() {
needs_config=0
module=$1
-component=$2
+component=$2
+confopts=$3
# preconds
if [ X$module = X ]; then
echo process() required first argument is missing
return 1
fi
-module_title $module $component
+module_title $module $component $confopts
SRCDIR=
CONFCMD=
-if [ -f $module/$component/autogen.sh ]; then
+if [ -f $module/$component/autogen.sh ]; then
SRCDIR=$module/$component
CONFCMD=autogen.sh
elif [ X$CLONE != X ]; then
-clone $module $component
+clone $module $component
if [ $? -eq 0 ]; then
SRCDIR=$module/$component
CONFCMD=autogen.sh
fi
needs_config=1
else
-checkfortars $module $component
+checkfortars $module $component
CONFCMD=configure
fi
@@ -451,7 +456,8 @@ process() {
${CPP:+CPP=$CPP} \
${CPPFLAGS:+CPPFLAGS=$CPPFLAGS} \
${CFLAGS:+CFLAGS=$CFLAGS} \
- ${LDFLAGS:+LDFLAGS=$LDFLAGS}
+ ${LDFLAGS:+LDFLAGS=$LDFLAGS} \
+ $confopts
if [ $? -ne 0 ]; then
failed ${CONFCMD} $module $component
cd $old_pwd
@@ -536,13 +542,15 @@ process() {
# LISTONLY, RESUME, NOQUIT, and BUILD_ONE
# arguments:
# $1 - module
-# $2 - component (optional)
+# $2 - component
+# $3 - configure options
# returns:
# 0 - good
# 1 - bad
build() {
module=$1
-component=$2
+component=$2
+confopts=$3
if [ X$LISTONLY != X ]; then
echo $module/$component
return 0
@@ -558,7 +566,7 @@ build() {
fi
fi
-process $module $component
+process $module $component $confopts
if [ $? -ne 0 ]; then
echo build.sh: error processing module/component:
\$module/$component\
if [ X$NOQUIT = X ]; then
@@ -1009,9 +1017,15 @@ process_module_file() {
continue
fi
- module=`echo $line | cut -d'/' -f1`
- component=`echo $line | cut -d'/' -f2`
- build $module $component
+ module=`echo $line | cut -d' ' -f1 | cut -d'/' -f1`
+ component=`echo $line | cut -d' ' -f1 | cut -d'/' -f2`
+ confopts_check=`echo $line | cut -d' ' -f2-`
+ if [ $module/$component = $confopts_check ]; then
+ confopts=
+ else
+ confopts=$confopts_check
+ fi
+ build $module $component $confopts
done $MODFILE
return 0
--
1.7.6.233.gd79bc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[driver/xf86-input-vmmouse] build problem from git sources
Hi everyone,
I'm trying to build the project sources on a fresh machine using the
modular build.sh procedure. Currently I'm experiencing a build failure
in driver/xf86-input-vmmouse and can't figure out how to fix it.
The build is having problems compiling
driver/xf86-input-vmmouse/src/vmmouse.c. At first I was seeing the
following:
vmmouse.c: In function 'VMMouseInitPassthru':
vmmouse.c:244:30: error: invalid application of 'sizeof' to incomplete
type 'InputOption'
vmmouse.c:245:10: error: dereferencing pointer to incomplete type
vmmouse.c:246:10: error: dereferencing pointer to incomplete type
vmmouse.c:247:10: error: dereferencing pointer to incomplete type
vmmouse.c:257:17: error: dereferencing pointer to incomplete type
vmmouse.c:258:16: error: dereferencing pointer to incomplete type
vmmouse.c:259:16: error: dereferencing pointer to incomplete type
But xserver/dix/inpututils.c also tries to perform a sizeof on the
InputOption type and succeeds. Comparing the two I added the following
line to driver/xf86-input-fmmouse/src/vmmouse.c:
#include optionstr.h
Afterwards I then received the following build error:
vmmouse.c: In function 'VMMouseInitPassthru':
vmmouse.c:246:10: error: 'InputOption' has no member named 'key'
vmmouse.c:247:10: error: 'InputOption' has no member named 'value'
vmmouse.c:248:10: error: 'InputOption' has no member named 'next'
vmmouse.c:258:17: error: 'InputOption' has no member named 'next'
vmmouse.c:259:16: error: 'InputOption' has no member named 'key'
vmmouse.c:260:16: error: 'InputOption' has no member named 'value'
The InputOption type is a typedef of _InputOption which appears to be
defined in $PREFIX/include/xorg/optionstr.h (which appears to come
from xserver/). In optionstr.h _InputOption is defined as:
struct _InputOption {
GenericListRec list;
char *opt_name;
char *opt_val;
int opt_used;
char *opt_comment;
};
Any idea how to reconcile this issue?
Best regards,
Trevor
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [driver/xf86-input-vmmouse] build problem from git sources
Hi Cyril, On Wed, Jan 4, 2012 at 4:31 PM, Cyril Brulebois k...@debian.org wrote: http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/26565 :-D Thank you. Sorry for not searching first. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xf86-input-synaptics] Add 'include' directory for test.
From: Trevor Woerner twoer...@gmail.com The binaries in the test directory won't build successfully for me without adding this include path. Signed-off-by: Trevor Woerner twoer...@gmail.com --- test/Makefile.am |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/test/Makefile.am b/test/Makefile.am index 0b45a2d..5dd8cdb 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -1,5 +1,5 @@ if ENABLE_UNIT_TESTS -AM_CPPFLAGS = -I$(top_srcdir)/src +AM_CPPFLAGS = -I$(top_srcdir)/src -I$(top_srcdir)/include AM_CFLAGS = $(XORG_CFLAGS) $(CWARNFLAGS) fake_syms = fake-symbols.c fake-symbols.h -- 1.7.4.1.227.gadfe4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xf86-input-aiptek] Address compiler warning.
From: Trevor Woerner twoer...@gmail.com When compiling gcc warns: 'rc' may be used uninitialized in this function which is plausible if none of the if/else cases are matched. Signed-off-by: Trevor Woerner twoer...@gmail.com --- src/xf86Aiptek.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/xf86Aiptek.c b/src/xf86Aiptek.c index f128fa0..d9a7665 100644 --- a/src/xf86Aiptek.c +++ b/src/xf86Aiptek.c @@ -1808,7 +1808,7 @@ xf86AiptekInit(InputDriverPtrdrv, InputInfoPtrpInfos; char* s; int shared; -int rc; +int rc = BadValue; aiptekDrv = drv; -- 1.7.4.rc1.3.gbc2d1 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xf86-input-acecad] Address compiler warnings - uninitialized use.
From: Trevor Woerner twoer...@gmail.com
When compiling prior to this patch, the following warnings are produced:
'report_x' may be used uninitialized in this function
'report_y' may be used uninitialized in this function
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
I don't know if this is the correct fix and have no means by which to test
these changes. However I'm guessing this might be better than using those
variables uninitialized (which is entirely possible if 'prox' is false).
src/acecad.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/acecad.c b/src/acecad.c
index 6259f21..6040b99 100644
--- a/src/acecad.c
+++ b/src/acecad.c
@@ -1000,14 +1000,15 @@ USBReadInput (InputInfoPtr local)
continue;
}
-if (prox)
-{
#if XORG_BOTCHED_INPUT
-ConvertProc(local, 0, 3, x, y, 0, 0, 0, 0, report_x, report_y);
+ConvertProc(local, 0, 3, x, y, 0, 0, 0, 0, report_x, report_y);
#else
-report_x = x;
-report_y = y;
+report_x = x;
+report_y = y;
#endif
+
+if (prox)
+{
if (!(priv-acecadOldProximity))
if (!is_core_pointer)
{
--
1.7.4.rc2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xf86-input-acecad 2/2] Compiler warning: defined but not used.
From: Trevor Woerner twoer...@gmail.com The function, 'ReverseConvertProc()', is no longer needed with the new XINPUT ABI. Signed-off-by: Trevor Woerner twoer...@gmail.com --- src/acecad.c |2 ++ src/acecad.h |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/acecad.c b/src/acecad.c index 6040b99..bdfe207 100644 --- a/src/acecad.c +++ b/src/acecad.c @@ -1072,6 +1072,7 @@ ConvertProc (InputInfoPtr local, int first, int num, } +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) 12 static Bool ReverseConvertProc (InputInfoPtr local, int x, int y, @@ -1086,6 +1087,7 @@ ReverseConvertProc (InputInfoPtr local, return TRUE; } +#endif #define WriteString(str)\ diff --git a/src/acecad.h b/src/acecad.h index a2b5c66..6660892 100644 --- a/src/acecad.h +++ b/src/acecad.h @@ -102,7 +102,9 @@ static Bool DeviceClose (DeviceIntPtr); static Bool DeviceInit (DeviceIntPtr); static void ReadInput (InputInfoPtr); static Bool ConvertProc (InputInfoPtr, int, int, int, int, int, int, int, int, int *, int *); +#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) 12 static Bool ReverseConvertProc(InputInfoPtr , int , int , int*); +#endif static Bool QueryHardware (AceCadPrivatePtr); static void NewPacket (AceCadPrivatePtr priv); static Bool AceCadGetPacket (AceCadPrivatePtr); -- 1.7.4.rc2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 modular 1/1] build.sh: use meaningful names for parameter variables
That's very nice, thanks for the work (and persistence) Reviewed-by: Trevor Woerner twoer...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH bitmap] Remove unused, leaky scanline.
From: Trevor Woerner twoer...@gmail.com
The pointer, scanline, doesn't appear to be used anymore, and is
leaking memory.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
bmtoa.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/bmtoa.c b/bmtoa.c
index bdd2078..5e48776 100644
--- a/bmtoa.c
+++ b/bmtoa.c
@@ -180,19 +180,12 @@ print_scanline (unsigned int width,
unsigned char *data,
char *chars)
{
-char *scanline = (char *) malloc (width + 1);
unsigned char *dp = data;
int row, column;
static unsigned char masktable[] = {
0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80 };
int padded = ((width 7) != 0);
-if (!scanline) {
- fprintf (stderr, %s: unable to allocate %d bytes for scanline\n,
-ProgramName, width + 1);
- exit (1);
-}
-
for (row = 0; row height; row++) {
for (column = 0; column width; column++) {
int i = (column 7);
--
1.7.4.rc1.3.gbc2d1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH bitmap] Fix memory leak.
On Fri, Jan 7, 2011 at 6:42 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: Is there any reason to malloc scanline at all? It appears entirely unused. good point :-) I've submitted a second patch to remove it entirely. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 1/2] build.sh: use meaningful names for parameter variables
I don't know if this should be part of the same patch or a new patch, but maybe (along the same lines) the variable names used in the checkfortars() function should use the same module and component pattern as all the other functions, instead of M and C? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 3/3] build.sh: rebuild a failing target with Automake silent rules disabled
Seems to work fine for me for the simple test I tried. Tested-by: Trevor Woerner twoer...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 16/16] build.sh: test return code directly when using echo/grep
I don't see how the original was flawed. But to me this change makes these ifs appear to not follow the formatting of all the other ifs in the script (there had been a decent effort in the past to make all the quoting and conditionals appear as similar as possible for uniformity's sake). ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 03/13] build.sh: allow user to specify an alternate bin directory
On Thu, Dec 30, 2010 at 10:59 AM, Gaetan Nadon mems...@videotron.ca wrote: This line does not work. EPREFIX has not been set by the user and has not been assigned a default value. That's too bad, the compounding defaults do get rather long. I was hoping for a simpler solution. Thanks for looking into my suggestion and trying it. I think patch 15 is a big improvement and I may be able to make it better later today. Yes, patch 15 does clean things up nicely. I'm looking forward to any further updates :-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 modular 15/15] build.sh: refactor installation directories initialization code
Yes, this is _much_ nicer :-) For the entire 15-part series: Reviewed-by: Trevor Woerner twoer...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 03/13] build.sh: allow user to specify an alternate bin directory
For this entire patch series I still can't understand why we need to define an explicit _SET variable which defines whether or not the base variable is defined, or not. For every one of the new variables you have defined you have included the following: +# States if the user has exported BINDIR +if [ X$BINDIR != X ]; then +BINDIR_SET=yes +fi And then you subsequently check to see if (using the specific variables for this specific patch) BINDIR_SET is defined to decide whether or not to use the value of BINDIR. But why? If BINDIR is not defined then BINDIR_SET will not be defined. So if you want to check whether BINDIR is defined why not just check to see if BINDIR is defined (instead of creating a new variable (BINDIR_SET) and checking whether it is defined or not)? Maybe there's something about what you're doing that I don't understand. But if you're defining BINDIR_SET only if BINDIR is defined and then using BINDIR_SET to indicate whether or not BINDIR is defined then I think you're adding complexity for no reason. PS. I have nothing against _what_ is being done, just the way in which it is being done. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 03/13] build.sh: allow user to specify an alternate bin directory
I see. Thanks for your patient and thorough explanation. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 03/13] build.sh: allow user to specify an alternate bin directory
Not to belabour the point too much, but I think the following patch
does what you want to do with #3 of this patch series:
diff --git a/build.sh b/build.sh
index 80452d3..465bd03 100755
--- a/build.sh
+++ b/build.sh
@@ -7,6 +7,8 @@ Environment variables specific to build.sh:
Each module/components is invoked with --prefix
EPREFIX Install architecture-dependent files in EPREFIX [PREFIX]
Each module/components is invoked with --exec-prefix
+ BINDIR Install user executables [EPREFIX/bin]
+ Each module/component is invoked with --bindir
QUIET Do not print messages saying which checks are being made
Each module/components is invoked with --quite
GITROOT Source code repository path [git://anongit.freedesktop.org/git]
@@ -67,7 +69,7 @@ setup_buildenv() {
export LD_LIBRARY_PATH
# Set the path so that locally built apps will be found and used
-PATH=${DESTDIR}${EPREFIX}/bin${PATH+:$PATH}
+PATH=${DESTDIR}${BINDIR-$EPREFIX/bin}${PATH+:$PATH}
export PATH
# Choose which make program to use
@@ -366,6 +368,7 @@ process() {
sh ${DIR_CONFIG}/${CONFCMD} \
--prefix=${PREFIX} \
${EPREFIX_SET:+--exec-prefix=$EPREFIX} \
+ ${BINDIR+--bindir=$BINDIR}
${LIB_FLAGS} \
${QUIET:+--quiet} \
${CONFFLAGS} \
Of the 3 changes, the first is the same as your original.
In the 2nd change: if BINDIR is set then it will be used in the PATH=
line, otherwise the default of $EPREFIX/bin will be substituted. If
you wanted to be more explicit, a variable called BINDIR_DEFAULT could
be defined as $EPREFIX/bin and used in this case.
For the 3rd change: if BINDIR does not exist then the
--bindir=$BINDIR configuration option will not be emitted.
No need for BINDIR_SET variables, no need for explicitly setting the
default value of BINDIR if BINDIR_SET is not defined. Or am I still
not getting it?
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 03/13] build.sh: allow user to specify an alternate bin directory
On Wed, Dec 29, 2010 at 9:58 PM, Gaetan Nadon mems...@videotron.ca wrote:
isn't it ${BINDIR:-$EPREFIX/bin} ?
These types of shell tests check whether or not the first value is
unset or null, omitting the colon results in a test only for a
parameter that is unset. So what I'm saying is you can set BINDIR to
and the script will still use that value (I'll let you choose to
have a blank BINDIR). Maybe that doesn't make sense?
CAVEAT: we should probably check with the Solaris guys to verify this
works in their shell? But I'm assuming it will because the other
variables are using something similar.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 1/8] build.sh: expose the PREFIX variable for the user to set
On Wed, Dec 22, 2010 at 9:34 AM, Gaetan Nadon mems...@videotron.ca wrote: I was contemplating another patch where PREFIX would not be mandatory and set /usr/local by default. This is what the autoconf does. That would be much more consistent with everything. What do you think? Yes, I think that would be the right thing to do :-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH bitmap] Fix memory leak.
From: Trevor Woerner twoer...@gmail.com
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
bmtoa.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/bmtoa.c b/bmtoa.c
index bdd2078..8cd96b1 100644
--- a/bmtoa.c
+++ b/bmtoa.c
@@ -208,6 +208,7 @@ print_scanline (unsigned int width,
putchar ('\n');
if (padded) dp++;
}
+free (scanline);
return;
}
--
1.7.3.4.598.g85356
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular] Add hooks to run a static analysis tool.
From: Trevor Woerner twoer...@gmail.com
I've added a new option to have a static analysis tool run over the code
while processing each module/component. I wrote it specifically with
the 'cppcheck' tool in mind but have hopefully made it generic enough
that any tool could be substituted.
The 'cppcheck' tool also comes with a reporting tool called
'cppcheck-htmlreport'. If 'cppcheck' is being used, the script will also
look for this reporting tool to generate nice html-based reports.
On the command-line specify the '--staticcheck' option to enable running
a static checker over the code. This option has one required argument:
a location into which to base the directory tree containing the reports.
If the environment variable 'STATICCHECK' is defined, it is assumed to
point to the static analysis tool to use, otherwise the script assumes
and looks for the 'cppcheck' utility.
If you want to pass different options to the static checker other than
the defaults you can define them in the environment variable
'STATICCHECK_OPTIONS', but I think the defaults are sufficient.
This option works well with the '-o' and '--modfile' options.
E.g.
util/modular/build.sh $PREFIX --staticcheck $HOME/reports
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
I saw the item the other day on lwn.net announcing a new project to add static
analysis checks on the Debian project and thought it would be nice to provide
a similar functionality to the X.Org codebase. Simply download, configure,
and install the 'cppcheck' tool and its daughter tool 'cppcheck-htmlreport',
use the --staticcheck option, provide a base directory for the reports
and see what comes out!
Hopefully these hooks have been written generically enough that you can
substitute whatever other static analysis tools with which you're familiar
(in case you don't like 'cppcheck' or want to try something else).
build.sh | 86 ++
1 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/build.sh b/build.sh
index 8568083..2dacf96 100755
--- a/build.sh
+++ b/build.sh
@@ -1,5 +1,7 @@
#!/bin/sh
+DEFAULT_STATICCHECK_OPTIONS=-v --enable=unusedFunction --force --xml
+
envoptions() {
cat EOF
Environment variables specific to build.sh:
@@ -13,6 +15,10 @@ Environment variables specific to build.sh:
Used to build the font path, search libraries and packages
FONTPATHPath to fonts directories [\$PREFIX/\$LIBDIR/X11/fonts/misc/,
...]
Picked-up by the xserver as a value for --with-default-font-path
+ STATICCHECK Specify static analysis tool to use if not the default [cppcheck]
+ STATICCHECK_OPTIONS
+ User-supplied options to static analysis tool to override the
defaults
+ [$DEFAULT_STATICCHECK_OPTIONS]
Environment variables defined by the GNU Build System:
DESTDIR Path to the staging area where installed objects are relocated
@@ -263,6 +269,43 @@ clone() {
return 0
}
+# perform static anaysis of code
+# arguments:
+# $1 - module
+# $2 - component (optional)
+# returns:
+# n/a
+staticcheck_analysis() {
+# preconds
+if [ X$1 = X ]; then
+ echo staticcheck_analysis() required argument \$1 missing
+ return
+fi
+
+# skip modules which obviously don't have source code (proto doc)
+case X$1 in
+ Xproto | Xdoc)
+ return
+ ;;
+esac
+
+if [ X$STATICCHECK != X ]; then
+ report_dir=$STATICCHECK_PREFIX/$1/$2
+ mkdir -p $report_dir
+ echo performing static analysis using '$STATICCHECK' with options
'${STATICCHECK_OPTIONS=$DEFAULT_STATICCHECK_OPTIONS}' on '$1/$2' and placing
report in '$report_dir/report.xml'
+ which tee /dev/null 21
+ if [ $? -eq 0 ]; then
+ $STATICCHECK ${STATICCHECK_OPTIONS=$DEFAULT_STATICCHECK_OPTIONS}
$1/$2 21 | tee $report_dir/report.xml
+ else
+ $STATICCHECK ${STATICCHECK_OPTIONS=$DEFAULT_STATICCHECK_OPTIONS}
$1/$2 $report_dir/report.xml 21
+ fi
+ if [ $? -eq 0 ] [ X$STATICCHECK_REPORT != X ]; then
+ echo generating static check report using 'cppcheck-htmlreport'
+ cppcheck-htmlreport --file=$report_dir/report.xml
--report-dir=$report_dir
+ fi
+fi
+}
+
# perform processing of each module/component
# arguments:
# $1 - module
@@ -308,6 +351,10 @@ process() {
echo $1/$2 $BUILT_MODULES_FILE
fi
+if [ X$STATICCHECK != X ]; then
+ staticcheck_analysis $1 $2
+fi
+
old_pwd=`pwd`
cd $SRCDIR
if [ $? -ne 0 ]; then
@@ -960,6 +1007,9 @@ usage() {
echo --check Run make check in addition \all install\
echo --clone Clone non-existing repositories (uses \$GITROOT if
set)
echo --cmd cmd Execute arbitrary git, gmake, or make command cmd
+echo --staticcheck report-prefix
+echo Perform static analysis on source, place results based
+echo
Re: [PATCH modular 2/8] build.sh: add support for EPREFIX for architecture-dependent files
On Sat, Dec 18, 2010 at 11:14 AM, Gaetan Nadon mems...@videotron.ca wrote:
On Thu, 2010-12-16 at 22:48 -0500, Trevor Woerner wrote:
Instead of doing all the EPREFIX_SET stuff, couldn't we just do:
+ ${EPREFIX:+--exec-prefix=$EPREFIX} \
and leave off the rest of this patch? We don't really need another
variable whose defined or undefined state lets us know whether EPREFIX
is defined or not :-)
That's what I first thought, then I realized the difference between $PREFIX
and the other ones. $PREFIX is a mandatory variable while the others are
not. We need the value from EPREFIX to compute the default values for other
variables, but we don't want to emit a command line with --exec-prefix on
each module.
Okay, ignoring this specific variable (PREFIX), for the rest of your
patches in this series would it be possible to remove the
VARIABLE_SET logic and just use the
${VARIABLE:+--what-have-you=$VARIABLE} ? I find all the extra
VAR_SET code extraneous.
In the specific case of PREFIX:
I did not want to invoke each module with a long list of --what-have-you
when they are all default values. In fact, I was thinking that perhaps we
should not make PREFIX mandatory. The configure script has a default value
usr/local when none supplied. That a separate question of course.
Yes, I agree. Following along the lines of my reply to your other
patch (making PREFIX available from the environment) I agree that it
would be nicer to follow the pattern of all other ./configure scripts:
the prefix is not a required argument, assume /usr/local unless told
otherwise.
Currently, all modules are invoked with --libdir even when the default value
is used, and that's bugging me. The user should be able to switch back and
forth between build.sh and configure for a particular module and not see a
different config.log which would trigger an investigation. How does he know
it is equivalent and not a script bug.
I would approve of such a cleanup. But that's just me :-)
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Add hooks to run a static analysis tool.
On Wed, Dec 22, 2010 at 12:19 AM, Peter Hutterer peter.hutte...@who-t.net wrote: why not make --cmd to perform arbitrary commands instead of limiting it to git and make? Was there a discussion on this before? I just went through my email archive and only found ones that focused on git and make, not on just running an arbitrary command. For my first iteration of this patch I had started by trying to add another allowed command to --cmd but it didn't work; it got too messy. --cmd doesn't allow any arbitrary command (it only allows 'git', 'make', and 'gmake') because the timing of when to run a git command is different than the timing of when to run a make (or gmake) command. If the user wants to run a git command the script will 'cd' into the source directory and then can run the git command and move on to the next module/component (without building). If the user wants to specify an arbitrary make command the script switches to the source directory, optionally runs the -p option, optionally switches to a build directory (which is different than the source directory), optionally configures the module/component, and then runs the arbitrary make command. In other words, the --cmd option has to know whether the arbitrary command is a git command (in which case it is run at one point) or a make command (so it is run at a different point in the build). If --cmd allowed any arbitrary command to be used the build.sh script would have no idea when to run it. When I first tried to wedge the static analysis into --cmd it was messy because the static analysis option requires the user to specify where to place the reports (I think it makes sense to place them somewhere outside of the PREFIX directory because otherwise 'make clean' operations wouldn't know to clean them up, causing distchecks and whatnot to fail). Plus I tried to make this option generic enough to run any static analysis tool, which would require the user to specify options to that other tool... all of which didn't fit into --cmd's git or make assumptions. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
xdm - xdmcp
The following commit in lib/libXdmcp: commit b64cac63e0bcdd87bbfd19678552fd7ed1a3b58f Author: Cristian RodrÃguez cristian.rodrig...@opensuse.org Date: Tue Dec 14 15:40:20 2010 -0500 Export only public API symbols Reviewed-by: Adam Jackson a...@redhat.com Signed-off-by: Cristian RodrÃguez cristian.rodrig...@opensuse.org Causes xdm to fail to build because app/xdm/xdm/genauth.c can't find the following symbols: _XdmcpAuthSetup _XdmcpAuthDoIt _XdmcpWrapperToOddParity ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH joystick 0/9] input abi fixes
For this series: Reviewed-by: Trevor Woerner twoer...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 1/8] build.sh: expose the PREFIX variable for the user to set
On Thu, Dec 16, 2010 at 9:31 PM, Gaetan Nadon mems...@videotron.ca wrote: Currently PREFIX is an internal build.sh variable which is used to emit the --prefix option to all modules. Make this variable part of the public interface and pick-up the value from the environment. Currently the user is expected to supply the PREFIX on the build.sh command-line. If the user's environment defines a variable named PREFIX and the user supplies the PREFIX on the cmdline, which one is supposed to win? If the environment defines the PREFIX should we remove the requirement to supply it on the cmdline? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 2/8] build.sh: add support for EPREFIX for architecture-dependent files
On Thu, Dec 16, 2010 at 9:31 PM, Gaetan Nadon mems...@videotron.ca wrote:
---
build.sh | 37 ++---
1 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/build.sh b/build.sh
index 4979fc0..80452d3 100755
--- a/build.sh
+++ b/build.sh
@@ -356,12 +358,15 @@ process() {
LIB_FLAGS=
if [ X$LIBDIR != X ]; then
- LIB_FLAGS=--libdir=${PREFIX}/${LIBDIR}
+ LIB_FLAGS=--libdir=${EPREFIX}/${LIBDIR}
fi
# Use sh autogen.sh since some scripts are not executable in CVS
if [ $needs_config -eq 1 ] || [ X$NOAUTOGEN = X ]; then
- sh ${DIR_CONFIG}/${CONFCMD} --prefix=${PREFIX} ${LIB_FLAGS} \
+ sh ${DIR_CONFIG}/${CONFCMD} \
+ --prefix=${PREFIX} \
+ ${EPREFIX_SET:+--exec-prefix=$EPREFIX} \
+ ${LIB_FLAGS} \
${QUIET:+--quiet} \
${CONFFLAGS} \
${CC:+CC=$CC} \
Instead of doing all the EPREFIX_SET stuff, couldn't we just do:
+ ${EPREFIX:+--exec-prefix=$EPREFIX} \
and leave off the rest of this patch? We don't really need another
variable whose defined or undefined state lets us know whether EPREFIX
is defined or not :-)
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH joystick 1/9] Replace LocalDevicePtr with InputInfoPtr
On Tue, Dec 14, 2010 at 9:58 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
Both typedefs describe the same struct, LocalDevicePtr has been removed with
input ABI 12.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
@@ -513,35 +513,35 @@ _X_EXPORT InputDriverRec JSTK_KEYBOARD = {
static InputInfoPtr
jstkCorePreInit(InputDriverPtr drv, IDevPtr dev, int flags)
{
- LocalDevicePtr local = NULL;
+ InputInfoPtr pInfo = NULL;
JoystickDevPtr priv = NULL;
char *s;
int i, j;
Maybe the above declaration could be kept aligned in the same way as
the other variables?
@@ -710,22 +710,22 @@ jstkCorePreInit(InputDriverPtr drv, IDevPtr dev, int
flags)
}
/* return the LocalDevice */
- local-flags |= XI86_CONFIGURED;
+ pInfo-flags |= XI86_CONFIGURED;
priv-keyboard_device = jstkKeyboardPreInit(JSTK_KEYBOARD, dev, flags);
if (priv-keyboard_device) {
priv-keyboard_device-private = priv;
}
- return (local);
+ return (pInfo);
SetupProc_fail:
if (priv)
free(priv);
- if (local)
- local-private = NULL;
+ if (pInfo)
+ pInfo-private = NULL;
return NULL;
-/* return (local); */ /* Makes X segfault on error */
+/* return (pInfo); */ /* Makes X segfault on error */
}
Maybe the last line could be removed altogether, since it's a comment anyway?
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH joystick 7/9] Don't call xf86OptionListReport()
xf86OptionListReport() still appears in src/jstk_key.c after this patch (but is removed by patch #9), is this okay ? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH joystick 5/9] Drop close_proc, conversion_proc, reverse_conversion_proc
Just out of curiosity... After applying this patch... 1) In src/jstk.c, line 490, jstkCorePreInit() the code is setting priv-close_proc to NULL. At line 423, jstkDeviceControlProc(), the code is calling priv-close_proc() but first checks to make sure it isn't NULL, at line 311 it is also calling priv-close_proc() but without the check. Could this potentially be a problem? 2) This patch removes the lines: pInfo-close_proc = NULL; pInfo-conversion_proc = NULL; from src/jstk.c but doesn't do the same for src/jstk_key.c. Is that okay? (I don't think InputInfoPtr contains those fields). I did notice they are removed with patch #9. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 1/4] build.sh: remove CACHE env variable as it is not implementable
On Sat, Dec 11, 2010 at 8:52 PM, Gaetan Nadon mems...@videotron.ca wrote:
For example, this cached variable from clock:
pkg_cv_XFT_LIBS=${pkg_cv_XFT_LIBS='-L/home/nadon/xorg/src/lib -lXft '}
is overwritten with the value from xdm:
pkg_cv_XFT_LIBS=${pkg_cv_XFT_LIBS='
-L/home/nadon/xorg/src/lib -lXrender -lX11 -lXft '}
Wouldn't that suggest there's a mistake in one or both of these settings?
They're both looking in the same directory ($HOME/xorg/src/lib) so
that's a good thing. But if clock only requires -lXft but xdm
requires all of -lXft, -lXrender, and -lX11 then maybe
something's wrong with how both projects setup the pkg_cv_XFT_LIBS
variable?
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 2/4] build.sh: use the script name only, not the path in usage statement
On Sat, Dec 11, 2010 at 8:53 PM, Gaetan Nadon mems...@videotron.ca wrote: - echo Usage: $0 [options] prefix + echo Usage: build.sh [options] prefix Personally I'd rather see: echo Usage: `basename $0` [options] prefix But then again, maybe we can't count on basename always being available, or working the same way on all platforms? :-D ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 4/4] build.sh: another pass at the env variable help text
Reviewed-by: Trevor Woerner twoer...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 3/4] build.sh: new layout and updated text for options usage
Looks nicer, thanks. Reviewed-by: Trevor Woerner twoer...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 1/4] build.sh: remove CACHE env variable as it is not implementable
On Mon, Dec 13, 2010 at 12:04 PM, Gaetan Nadon mems...@videotron.ca wrote: On Mon, 2010-12-13 at 11:11 -0500, Trevor Woerner wrote: Wouldn't that suggest there's a mistake in one or both of these settings? They're both looking in the same directory ($HOME/xorg/src/lib) so that's a good thing. But if clock only requires -lXft but xdm requires all of -lXft, -lXrender, and -lX11 then maybe something's wrong with how both projects setup the pkg_cv_XFT_LIBS variable? The name of the variable is purely arbitrary. It means different things to different modules. I don't really understand how this Autoconf feature can be useful. Perhaps if the modules configuration is very vanilla, things like CC don't change so you get some benefit. Maybe there is something I don't understand. http://www.gnu.org/software/automake/manual/autoconf.html#Caching-Results It looks to me that this feature made the assumptions that there would be no name clashing. Thanks for looking into this, I need to be convinced it is safe to use. I have been using the --cache-file feature for years (on other projects, of course). Although I've never timed its operation, it certainly _seems_ to speed up the configuration process since, roughly, 90% or more of the variables are the same between all builds and don't need to be recalculated over and over again. For example, anytime configure.ac uses a built-in test (e.g. AC_PROG_YACC) the variables and the test will be the same, so it would only need to be calculated once, then the results could just be reused for all future such checks. I hadn't noticed it causing any build problems, but I'll keep an eye out for it. In the example you noticed, pkg_cv_XFT_LIBS, both packages are looking for the Xft library which they both get, xdm just includes a couple extra (which is probably not as efficient). ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 1/4] build.sh: remove CACHE env variable as it is not implementable
On Mon, Dec 13, 2010 at 7:03 PM, Gaetan Nadon mems...@videotron.ca wrote: The resulting variables XORG_CFLAGS and XORG_LIBS are unique to each package and hold different values. This is where I think the concept of a cache does not hold. The last write wins and if you pick a random package to rebuild, it will pick the value written last. Ah okay, I think I see where you're going. In my original email I was trying to say: maybe all the variables between all the packages should be coordinated so they don't clash but seeing how huge of a job that would be it's probably much safer this way. I'm guessing it's probably not being used by many people, and I'm all for getting rid of clutter :-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 1/4] build.sh: remove CACHE env variable as it is not implementable
On Mon, Dec 13, 2010 at 8:04 PM, Gaetan Nadon mems...@videotron.ca wrote: I assume it's an Acked-by from at least Trevor to remove this from build.sh so new comers (or myself!) don't get burned on this. Yes, it has my consent :-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 modular 1/3] build.sh: remove USE_XCB interface for libX11
Looks good :-) Reviewed-by: Trevor Woerner twoer...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 modular 3/3] build.sh: provide a new implementation for the -g option
Reviewed by: Trevor Woerner twoer...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH penmount 00/10] cleanup and ABI 12 support
I've verified that applying the 10 patches in this series allows the penmount driver to build correctly without warnings (on Linux x86). For this series: Reviewed-by: Trevor Woerner twoer...@gmail.com On Wed, Dec 1, 2010 at 11:37 PM, Peter Hutterer peter.hutte...@who-t.net wrote: untested, no device. changes are the usual combination of cleanup and ABI changes. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 1/3] build.sh: remove USE_XCB interface for libX11
Additionally, there's a 2-line comment on lines 525 and 526 talking about _if_ you're building xcb with libX11 which could be removed. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 2/3] build.sh: support CC, CPP, CPPFLAGS and CFLAGS
On Thu, Dec 2, 2010 at 7:52 PM, Gaetan Nadon mems...@videotron.ca wrote: Signed-off-by: Gaetan Nadon mems...@videotron.ca Reviewed-by: Trevor Woerner twoer...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 3/3] build.sh: provide a new implementation for the -g option
On Thu, Dec 2, 2010 at 7:52 PM, Gaetan Nadon mems...@videotron.ca wrote: as a vehicule to forward C flags to module configuration, but vehicle CONFFLAGS: additional flags to pass to all configure scripts Since you've added all the standard variable names, should CONFFLAGS be removed too? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH aiptek 14/18] Use pInfo-name instead of dev-identifier
After applying this patch there's still one left at line 2050 of src/xf86Aiptek.c is this significant? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH aiptek 15/18] Drop close_proc, conversion_proc, reverse_conversion_proc
In this patch you remove the reference to xf86AiptekClose, but I don't think that function is removed in this patch. On Wed, Dec 1, 2010 at 9:13 PM, Peter Hutterer peter.hutte...@who-t.net wrote: /** * xf86AiptekSendEvents * Send events according to the device state. @@ -1799,10 +1672,7 @@ xf86AiptekAllocate(char* name, pInfo-device_control = xf86AiptekProc; pInfo-read_input = xf86AiptekHIDReadInput; pInfo-control_proc = xf86AiptekChangeControl; - pInfo-close_proc = xf86AiptekClose; pInfo-switch_mode = xf86AiptekSwitchMode; - pInfo-conversion_proc = xf86AiptekConvert; - pInfo-reverse_conversion_proc = xf86AiptekReverseConvert; ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH aiptek 15/18] Drop close_proc, conversion_proc, reverse_conversion_proc
On Wed, Dec 1, 2010 at 10:20 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Dec 01, 2010 at 10:15:49PM -0500, Trevor Woerner wrote: In this patch you remove the reference to xf86AiptekClose, but I don't think that function is removed in this patch. xf86AiptekClose() is called directly during DEVICE_OFF and DEVICE_CLOSE, see xf86AiptekProc(). Okay, thanks :-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH aiptek 00/18] Cleanup and input ABI 12
I have verified that after applying these 18 patches the xf86-input-aiptek driver compiles successfully. For this series: Reviewed-by: Trevor Woerner twoer...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 2/2] Remove build-from-tarballs script.
From: Trevor Woerner twoer...@gmail.com
The build.sh script is able to perform builds from tarballs.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
It is my understanding that the build-from-tarballs script doesn't work.
Personally I don't know since I've never used it. The build.sh script has
been patched (thanks to the contribution of others) to work with tarballs.
I don't think we need 2 procedures for building from tarballs, especially
since one, currently, doesn't work. Instead of fixing build-from-tarballs
maybe it would be better to remove the duplication of work?
build-from-tarballs.sh | 589
1 files changed, 0 insertions(+), 589 deletions(-)
delete mode 100755 build-from-tarballs.sh
diff --git a/build-from-tarballs.sh b/build-from-tarballs.sh
deleted file mode 100755
index 27731cc..000
--- a/build-from-tarballs.sh
+++ /dev/null
@@ -1,589 +0,0 @@
-#!/bin/sh
-
-# global environment variables you may set:
-# CACHE: absolute path to a global autoconf cache
-# QUIET: hush the configure script noise
-# CONFFLAGS: flags to pass to all configure scripts
-
-failed() {
-if test x$NOQUIT = x1; then
- echo * $1 failed on $2/$3
-else
- exit 1
-fi
-}
-
-build() {
-test $USEMODULEDIRS = yes cd $1
-
-TARBALL=`ls -1rt $2-*.tar.$COMPRESSION 2 /dev/null | tail -n 1`
-
-if test x$TARBALL = x; then
- echo WARNING: $2 does not exist -- skipping
- test $USEMODULEDIRS = yes cd ..
- return
-fi
-TARDIR=`echo $TARBALL | sed s,.tar.$COMPRESSION,,`
-
-echo Building $1 module component $TARDIR...
-
-case $COMPRESSION in
- bz2)
- tar xjf $TARBALL
- break;;
- gz)
- tar xvf $TARBALL
- break;;
-esac
-
-cd $TARDIR
-
-if test $1 = xserver test $2 = xorg-server test -n
$MESAPATH; then
- MESA=--with-mesa-source=${MESAPATH}
-else
- MESA=
-fi
-
-eval sh configure --prefix=${PREFIX} ${MESA} ${QUIET:+--quiet} \
-${CACHE:+--cache-file=}${CACHE} ${CONFFLAGS} || failed configure $1 $2
-make || failed make $1 $2
-if test x$CLEAN = x1; then
- make clean || failed clean $1 $2
-fi
-if test x$DIST = x1; then
- make dist || failed dist $1 $2
-fi
-if test x$DISTCHECK = x1; then
- make distcheck || failed distcheck $1 $2
-fi
-$SUDO env LD_LIBRARY_PATH=$LD_LIBRARY_PATH make install || \
- failed install $1 $2
-
-cd ..
-test $USEMODULEDIRS = yes cd ..
-}
-
-# protocol headers have no build order dependencies
-build_proto() {
-build proto applewmproto
-build proto bigreqsproto
-build proto compositeproto
-build proto damageproto
-build proto dmxproto
-build proto evieext
-build proto fixesproto
-build proto fontcacheproto
-build proto fontsproto
-build proto glproto
-build proto inputproto
-build proto kbproto
-build proto randrproto
-build proto recordproto
-build proto renderproto
-build proto resourceproto
-build proto scrnsaverproto
-build proto trapproto
-build proto videoproto
-build proto windowswmproto
-build proto xcmiscproto
-build proto xextproto
-build proto xf86bigfontproto
-build proto xf86dgaproto
-build proto xf86driproto
-build proto xf86miscproto
-build proto xf86vidmodeproto
-build proto xineramaproto
-build proto xproto
-}
-
-# bitmaps is needed for building apps, so has to be done separately first
-# cursors depends on apps/xcursorgen
-# xkbdata depends on apps/xkbcomp
-build_data() {
-#build data xbitmaps
-build data xcursor-themes
-build data xkbdata
-}
-
-# All protocol modules must be installed before the libs (okay, that's an
-# overstatement, but all protocol modules should be installed anyway)
-#
-# the libraries have a dependency order:
-# xtrans, Xau, Xdmcp before anything else
-# fontenc before Xfont
-# ICE before SM
-# X11 before Xext
-# (X11 and SM) before Xt
-# Xt before Xmu and Xpm
-# Xext before any other extension library
-# Xfixes before Xcomposite
-# Xp before XprintUtil before XprintAppUtil
-build_lib() {
-build lib xtrans
-build lib libXau
-build lib libXdmcp
-build lib libX11
-build lib libXext
-build lib libAppleWM
-build lib libWindowsWM
-build lib libdmx
-build lib libfontenc
-build lib libFS
-build lib libICE
-#build lib liblbxutil
-#build lib liboldX
-build lib libSM
-build lib libXt
-build lib libXmu
-build lib libXpm
-build lib libXaw
-build lib libXfixes
-build lib libXcomposite
-build lib libXrender
-build lib libXdamage
-build lib libXcursor
-build lib libXevie
-build lib libXfont
-build lib libXfontcache
-build lib libXft
-build lib libXi
-build lib libXinerama
-build lib libxkbfile
-build lib libxkbui
-build lib libXrandr
-build lib libXres
Re: [PATCH modular 2/2] Remove build-from-tarballs script.
On Wed, Nov 24, 2010 at 5:32 PM, Peter Hutterer peter.hutte...@who-t.net wrote: assuming build.sh works with tarballs as you said (I haven't tried) To clarify, I haven't tried either, I'm relying on reports from others. But I will test this out and familiarize myself with the process. Reviewed-by: Peter Hutterer peter.hutte...@who-t.net Thanks. can you please trawl the wiki and change the references to build-from-tarballs.sh to the new flags used by build.sh? Sure, no problem. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libICE docs] Add top-level target for documentation.
On Tue, Nov 23, 2010 at 11:57 AM, Matt Dew m...@osource.org wrote: Something I've been wondering. Is there a need to have both specs and doc dirs? Can they be merged? Interesting. Just a cursory glance at a small number of the projects with documentation (http://www.x.org/wiki/Development/Documentation/WritingDocumentation) shows there's a bit of a discrepancy: libSM: doc libX11: man, specs libXaw: man, specs, old-doc libXcomposite: man libXi: doc, man, specs So I can predict Gaetan replying to my previous email saying: let's use 'install-docs' since not all projects have a specs directory and we want to use the same target across all projects :-D Sorry, I have no idea if this can or should be cleaned up. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libICE docs] Add top-level target for documentation.
On Tue, Nov 23, 2010 at 12:25 PM, Gaetan Nadon mems...@videotron.ca wrote: The alternative is to implement the feature (let's call it build all docs) in build.sh. It already contains the list of all modules, it's just a matter of invoking the right doc targets. Some option like --build-docs-only would be even easier to use. Let me know how that sounds. That sounds great to me, I can get started on that. Maybe we should leave off the build part since we're both building and installing? The only question I have remaining is: if I user invokes build.sh with this new option, what are they expecting to see built and installed? man pages? specs? developer documentation? all of the above? I'm guessing you just want the specs and developer documentation, but I just wanted to be double-check. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular] Remove lib only option from build.sh.
From: Trevor Woerner twoer...@gmail.com
Now that a user of build.sh has the ability to pick and choose which
subprojects to process via the --modfile option, having an option
to only build libraries is redundant.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
I acknowledge that some people will, rightly so, not agree with this patch
since -l is an existing option which I am suggesting be removed. But since
the newer --modfile option is more flexible and fully encompasses the -l
functionality I see this as a nice, reasonable, cleanup.
build.sh | 23 ---
1 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/build.sh b/build.sh
index 6a38635..a0a1955 100755
--- a/build.sh
+++ b/build.sh
@@ -952,7 +952,6 @@ usage() {
echo -d : run make distcheck in addition to others
echo -g : build with debug information
echo -h | --help : display this help and exit successfully
-echo -l : build libraries only (i.e. no drivers, no docs, etc.)
echo -n : do not quit after error; just print error message
echo -o module/component : build just this component
echo -p : run git pull on each component
@@ -972,7 +971,6 @@ usage() {
HAVE_ARCH=`uname -i`
DIR_ARCH=
DIR_CONFIG=.
-LIB_ONLY=0
PREFIX=
# perform sanity checks on cmdline args which require arguments
@@ -1039,9 +1037,6 @@ do
-L)
LISTONLY=1
;;
--l)
- LIB_ONLY=1
- ;;
-n)
NOQUIT=1
;;
@@ -1164,16 +1159,14 @@ if [ X$MODFILE = X ]; then
build_lib
build_mesa
-if [ $LIB_ONLY -eq 0 ]; then
- build_doc
- build data bitmaps
- build_app
- build_xserver
- build_driver
- build_data
- build_font
- build_util
-fi
+build_doc
+build data bitmaps
+build_app
+build_xserver
+build_driver
+build_data
+build_font
+build_util
else
process_module_file
fi
--
1.7.3.2.245.g03276
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH libICE docs] Add top-level target for documentation.
From: Trevor Woerner twoer...@gmail.com Builds user and developer documentation/specifications. Signed-off-by: Trevor Woerner twoer...@gmail.com --- Makefile.am |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/Makefile.am b/Makefile.am index c2110ec..d0102e8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -5,7 +5,7 @@ pkgconfig_DATA = ice.pc MAINTAINERCLEANFILES = ChangeLog INSTALL -.PHONY: ChangeLog INSTALL +.PHONY: ChangeLog INSTALL documents INSTALL: $(INSTALL_CMD) @@ -15,6 +15,11 @@ ChangeLog: dist-hook: ChangeLog INSTALL +# Generically invoked from build.sh --cmd make documents +# Builds User's documentation and Developer's documentation/specifications +documents: + cd specs $(MAKE) $(AM_MAKEFLAGS) install + if LINT lint: (cd src $(MAKE) $(MFLAGS) lint) -- 1.7.3.2.245.g03276 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libICE docs] Add top-level target for documentation.
On Mon, Nov 22, 2010 at 7:21 PM, Gaetan Nadon mems...@videotron.ca wrote: On Mon, 2010-11-22 at 17:26 -0500, Trevor Woerner wrote: -.PHONY: ChangeLog INSTALL +.PHONY: ChangeLog INSTALL documents I don't think it should be a PHONY target, documents is not a file. It's like the lint target. I thought this is exactly the sort of scenario where a PHONY target is used. From info make: A phony target is one that is not really the name of a file. It is just a name for some commands to be executed when you make an explicit request. In other words, when you're done performing make documents you don't actually end up with a file called documents the way you would if you did, say, a make hello in a hello world project. make documents is just a way to invoke this set of commands from within the Makefile. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: How to get a list of windows and process mapping
On Tue, Nov 16, 2010 at 3:44 PM, Adam Majer ad...@zombino.com wrote: Is there a method of getting a list of all the windows on a given display or screen? Is there a method of mapping these Windows to host/pid? Maybe having a look at xwininfo (and its sources) will help get you started? $ xwininfo -root -tree -wm ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: driver/xf86-input-keyboard wants IDevPtr
Of the 10 input drivers of which build.sh is aware: driver/xf86-input-aiptek driver/xf86-input-evdev driver/xf86-input-joystick driver/xf86-input-vmmouse driver/xf86-input-acecad driver/xf86-input-keyboard driver/xf86-input-mouse driver/xf86-input-penmount driver/xf86-input-synaptics driver/xf86-input-void The following drivers fail to compile due to this same issue: driver/xf86-input-aiptek driver/xf86-input-joystick driver/xf86-input-acecad driver/xf86-input-keyboard driver/xf86-input-mouse driver/xf86-input-penmount driver/xf86-input-void In other words only the following successfully compile: driver/xf86-input-evdev driver/xf86-input-vmmouse driver/xf86-input-synaptics All from the same issue you mention. I had started trying to fix up the driver/xf86-input-aiptek driver to try to get it compiling again but ran into the issue that the semantics of InputDriverRec's PreInit function changed from returning a InputInfoPtr to returning a status. If it were simply a matter of search and replace with the appropriate ABI checks I could have handled it, but with the changing semantics I'm not so sure and would need more guidance. Best regards, Trevor ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular] Remove local variables.
From: Trevor Woerner twoer...@gmail.com
Fix build to work on Solaris 10, which doesn't understand the
'local' keyword.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
build.sh |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/build.sh b/build.sh
index 69aef7f..f7b9517 100755
--- a/build.sh
+++ b/build.sh
@@ -259,8 +259,7 @@ clone() {
# 0 - good
# 1 - bad
process() {
-local rtn
-local needs_config=0
+needs_config=0
# preconds
if [ X$1 = X ]; then
@@ -912,10 +911,6 @@ build_doc() {
# 0 - good
# 1 - bad
process_module_file() {
-local line
-local module
-local component
-
# preconds
if [ X$MODFILE = X ]; then
echo internal process_module_file() error, \$MODFILE is empty
--
1.7.3.2.164.g6f10c
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Remove -f and -r options.
Hi Dan, Thanks for your input. On Thu, Nov 11, 2010 at 3:23 PM, Dan Nicholson dbn.li...@gmail.com wrote: Why don't you make -f and -r map to --autoresume instead of removing them. Well, I was hoping to free up those options, in case someone finds something new to add, and remove un/little-used cruft :-) In fact, I'd think -f/--file would be a nicer option name to keep than --autoresume. autoresume is quite a lot more descriptive than file; we also have modfile which requires an optional file parameter. So there are two options which require a file, naming one of them file wouldn't be very helpful :-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Remove -f and -r options.
Hi Dan, On Fri, Nov 12, 2010 at 8:45 AM, Dan Nicholson dbn.li...@gmail.com wrote: I would think changing the interface on people with no warning would be something to avoid. Well yes, of course. that's why I sent this patch to the mailing list for public comment... this is the warning. This isn't code which has already been committed. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular] Verify existence of command specified by --cmd.
From: Trevor Woerner twoer...@gmail.com If the user specifies a 'git' or 'g/make' --cmd, make sure it exists before trying to use it. Signed-off-by: Trevor Woerner twoer...@gmail.com --- build.sh | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/build.sh b/build.sh index 275a1e1..bf67ebd 100755 --- a/build.sh +++ b/build.sh @@ -1059,6 +1059,16 @@ do shift cmd1=`echo $1 | cut -d' ' -f1` cmd2=`echo $1 | cut -d' ' -f2` + + # verify the command exists + which $cmd1 /dev/null 21 + if [ $? -ne 0 ]; then + echo The specified command '$cmd1' does not appear to exist + echo + usage + exit 1 + fi + case X$cmd1 in Xgit) GITCMD=$1 -- 1.7.3.2.146.gca209 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] build.sh: allow tarballs with --modfile
Thanks for sending me the patch. Yes, there's no doubt, when I added the --modfile option I absolutely assumed the user would be building from git sources; enabling --clone definitely ignores building from tarballs. I agree that your patch is required: Reviewed-by: Trevor Woerner twoer...@gmail.com In an effort to make the script smarter, I have created an additional patch on top of yours whereby: if the user forgets to provide the --clone flag and there are neither sources nor tarballs, assume they should have provided the --clone flag and grab the sources from git. Would that be an unexpected assumption? (I'll be sending that patch shortly after sending this email) On Wed, Nov 3, 2010 at 7:21 AM, Simon Braunschmidt s...@emlix.com wrote: I would rather suggest to get rid of/obsolete build-from-tarballs.sh and manage it all from build.sh. ... Would patches to integrate all of build-from-tarballs.sh into build.sh with the purpose to remove build-form-tarballs.sh be accepted? I think this would be a good cleanup. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] build.sh: allow tarballs with --modfile
On Wed, Nov 3, 2010 at 8:20 AM, Trevor Woerner twoer...@gmail.com wrote: In an effort to make the script smarter, I have created an additional patch on top of yours whereby: if the user is using the --modfile option AND if the user forgets to provide the --clone flag and there are neither sources nor tarballs, assume they should have provided the --clone flag and grab the sources from git. Would that be an unexpected assumption? (I'll be sending that patch shortly after sending this email) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular] Clone if there are no source files with modfile.
From: Trevor Woerner twoer...@gmail.com
If the user has not supplied the --clone flag but is using a --modfile
and there are neither sources or tarballs, assume --clone.
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
build.sh | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/build.sh b/build.sh
index 1593f4d..9878c4c 100755
--- a/build.sh
+++ b/build.sh
@@ -240,16 +240,21 @@ process() {
if [ -f $1/$2/autogen.sh ]; then
SRCDIR=$1/$2
CONFCMD=autogen.sh
-elif [ X$CLONE != X ]; then
+else
+checkfortars $1 $2
+CONFCMD=configure
+fi
+
+# if the user has provided the --clone flag OR
+# if there are no sources or tarballs but a module file has been provided
+# the user wants to build from git sources
+if [ X$CLONE != X ] || ( [ X$CONFCMD = X ] [ X$MODFILE != X ] );
then
clone $1 $2
if [ $? -eq 0 ]; then
SRCDIR=$1/$2
CONFCMD=autogen.sh
fi
needs_config=1
-else
-checkfortars $1 $2
-CONFCMD=configure
fi
if [ X$SRCDIR = X ]; then
--
1.7.3.1.127.g1bb28
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] build.sh: verbose error output for missing components
On Wed, Nov 3, 2010 at 9:47 AM, Simon Braunschmidt sbr...@emlix.com wrote: Instead of Trevor Woerners proposal to automagically clone missing components, I would rather want to inform the user more verbosely about missing components and how to obtain them. That's true. Assumptions always seem to have a way of not always doing what a user expects :-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Clone if there are no source files with modfile.
I *think* Peter Hutterer added it (according to git annotate) On Wed, Nov 3, 2010 at 10:14 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: No comment on that patch, but I do want to express my appreciation for --clone - it made it much easier to get a new full build set going in the new virtualbox instance I set up for testing Linux builds before pushing out the katamari release bits. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Clone if there are no source files with modfile.
Thanks, Peter, for the ACK, but I think this one's dead. If the user misuses the script, it's probably best to not try to guess what the user wanted to do. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Fwd: Google Code-In: Do we want to partcipate?]
I'd be happy to mentor someone to complete the task of converting xalloc/xcalloc/xfree. I could also help someone with the KR conversion or adding gettext i18n support to the applications. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 2/2] Verify existence of command specified by --cmd.
On Sat, Oct 23, 2010 at 8:03 PM, Gaetan Nadon mems...@videotron.ca wrote: On Fri, 2010-10-22 at 16:08 -0400, Trevor Woerner wrote: + which $cmd1 /dev/null 2 /dev/null I am not UNIX head, but it seems '$cmd1 /dev/null 21' would be a more popular way to write this. Ha ha! Yes, that's how my fingers would more naturally phrase such a thing. But I *believe* that is a bash-ism. I tried to be as generic as I possibly could by reviewing the automake/autoconf/m4 script gotchas someone referred us to a while back (I think it was Alan Coopersmith). Reviewing the pertinent sections I believe what I wrote is the most generic, but I could be wrong. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Allow --cmd option to accept 'gmake'.
On Fri, Oct 22, 2010 at 3:47 PM, Gaetan Nadon mems...@videotron.ca wrote: $ util/modular/build.sh -o util/macros --cmd bogus /home/nadon/xorg/src The script can only process 'make', 'gmake', or 'git' commands It can't process 'bogus' commands The reason I differentiate between make-ish commands and git-ish commands is because in the processing phase they are handled in different locations. Any git-ish command is handled early, then the rest of the processing is skipped. Any make-ish commands are processed after: - checking for pull - building outside the source directory - running the autogen.sh/configure So basically, the script wouldn't know when to perform the arbitrary command; whether it should be done early, or after a lot of other processing. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 2/2] Verify existence of command specified by --cmd.
From: Trevor Woerner twoer...@gmail.com Signed-off-by: Trevor Woerner twoer...@gmail.com --- build.sh | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/build.sh b/build.sh index 8d7b5bf..1898d33 100755 --- a/build.sh +++ b/build.sh @@ -1060,6 +1060,16 @@ do shift cmd1=`echo $1 | cut -d' ' -f1` cmd2=`echo $1 | cut -d' ' -f2` + + # verify the command exists + which $cmd1 /dev/null 2 /dev/null + if [ $? -ne 0 ]; then + echo The specified command '$cmd1' does not appear to exist + echo + usage + exit 1 + fi + case X$cmd1 in Xgit) GITCMD=$1 -- 1.7.3.1.127.g1bb28 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xf86-video-tseng] Convert x+m/calloc/free to m/calloc/free.
From: Trevor Woerner twoer...@gmail.com
Signed-off-by: Trevor Woerner twoer...@gmail.com
---
src/tseng_dga.c|4 ++--
src/tseng_driver.c | 10 +-
src/tseng_mode.c |2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/tseng_dga.c b/src/tseng_dga.c
index 70ebe23..cb57dfe 100644
--- a/src/tseng_dga.c
+++ b/src/tseng_dga.c
@@ -74,9 +74,9 @@ TsengDGAInit(ScreenPtr pScreen)
if (!pTseng-DGAnumModes) {
pMode = firstMode = pScrn-modes;
while (pMode) {
- newmodes = xrealloc(modes, (num + 1) * sizeof (DGAModeRec));
+ newmodes = realloc(modes, (num + 1) * sizeof (DGAModeRec));
if (!newmodes) {
- xfree(modes);
+ free(modes);
return FALSE;
}
modes = newmodes;
diff --git a/src/tseng_driver.c b/src/tseng_driver.c
index 445c17e..6992671 100644
--- a/src/tseng_driver.c
+++ b/src/tseng_driver.c
@@ -269,9 +269,9 @@ TsengFreeRec(ScrnInfoPtr pScrn)
pTseng = TsengPTR(pScrn);
if (pTseng-SavedReg.RAMDAC)
-xfree(pTseng-SavedReg.RAMDAC);
+free(pTseng-SavedReg.RAMDAC);
-xfree(pScrn-driverPrivate);
+free(pScrn-driverPrivate);
pScrn-driverPrivate = NULL;
}
@@ -395,10 +395,10 @@ TsengProbe(DriverPtr drv, int flags)
foundScreen = TRUE;
}
}
-xfree(usedChips);
+free(usedChips);
}
-xfree(devSections);
+free(devSections);
return foundScreen;
}
@@ -806,7 +806,7 @@ TsengProcessOptions(ScrnInfoPtr pScrn)
xf86CollectOptions(pScrn, NULL);
/* Process the options */
-if (!(pTseng-Options = xalloc(sizeof(TsengOptions
+if (!(pTseng-Options = malloc(sizeof(TsengOptions
return FALSE;
memcpy(pTseng-Options, TsengOptions, sizeof(TsengOptions));
xf86ProcessOptions(pScrn-scrnIndex, pScrn-options, pTseng-Options);
diff --git a/src/tseng_mode.c b/src/tseng_mode.c
index f075226..7649efd 100644
--- a/src/tseng_mode.c
+++ b/src/tseng_mode.c
@@ -1502,7 +1502,7 @@ TsengModeInit(ScrnInfoPtr pScrn, DisplayModePtr OrigMode)
/* clean up */
if (new-RAMDAC)
-xfree(new-RAMDAC);
+free(new-RAMDAC);
return TRUE;
}
--
1.7.3.1.127.g1bb28
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
