contribute to the open source community

disparv · 2012-06-09 15:34:11

I've been programming for a couple of years now, but always my own projects.
Now I wan't to learn by helping the open source community and submitting patches etc...

What I don't understand is how to test the changes I made in a program.

So let's say I made some changes to xfwm4(xfce's window manager). What is the correct way to test my changes?:
Just leave the executables in the build dir?
Use 'make install'? ( to /usr/bin/local )
Should I install it under a different name? e.g 'xfwm4_custom'

-- Thanks for the help

Cloudef · 2012-06-09 16:35:45

Testing is quite project centric. If you are interested in XFCE4 deveploment, I suggest joining their IRC/Mailing list whatever and asking how the people do it there.

Last edited by Cloudef (2012-06-09 16:35:59)

cmtptr · 2012-06-09 16:59:16

I usually use alias or shell script hackery to run whatever I'm working on in-place, with the "official" pkg still installed for other users (in the ~5 years I've been using linux I've never had another user on any of my personal machines, but you never know!!).

For example, recently I've been screwing around with the awesome source. So I replaced the following line in my ~/.xinitrc:

exec awesome

With this:

LUA_PATH=";;$HOME/src/awesome/build/lib/?.lua;$HOME/src/awesome/build/lib/?/init.lua" exec "$HOME/src/awesome/awesome"

Other environment variables that are often necessary include PATH and LD_LIBRARY_PATH.

The same goes for when I'm tracking down wine regressions - I write a launcher script to set up whatever environment variables are necessary and then launch wine straight from the directory where it was built.

disparv · 2012-06-09 17:42:28

Cloudef wrote:

Testing is quite project centric. If you are interested in XFCE4 deveploment, I suggest joining their IRC/Mailing list whatever and asking how the people do it there.

Ye was about to do that, thanks for the answers btw.

pilotkeller · 2012-06-09 17:53:28

My favorite way is my dev box. It is simply an old laptop (The 2 inch think IMB type) that I load my modified version onto and stress test under 4 distros (Fedora, Suse, Arch, and Debian). I run an OpenSSH daemon on my primary so I can SFTP to grab the file and test away. If you somehow manage to completely brick the system (Acheivement Unclocked: Kill the box from within userland!) it's only a beater, and you can reimage at will. You can likely find a computer like this on ebay/craigslist for FREE-$20.

You could just take the dual boot route with a dedicated dev distro.

Another popular way is under VMware/VBox.

there is also running it ~ based. Just make a ~/bin folder and add it to your $PATH in your shell rc file.

There are obviously hundreds of ways to do anything... It's Linux! Just find your way and you'll be all set.

Honestly the best thing to start with in OSS is always lib dev. It allows a very safe dev process until you become familiar with the way team based software dev works using the many software visioning platforms. This is because the software is easily testable and the code is extremely modular. You can work on your method/function and usually never have to worry that your commit will conflict with another. Also it usually prevents needing to worry about xlib interaction.

Last edited by pilotkeller (2012-06-09 17:53:58)

Trilby · 2012-06-09 19:32:30

For some projects I've created PKGBUILDS and used some name extension to tell the packages appart.

An example was when I was tinkering with xpdf. I wanted to disable the dialog asking for confimation before following a link or running a script as I would only open presentation pdfs I made with it. I called my version xpdf-noask. I could then install it with makepkg/pacman and it would replace the normal xpdf, I could try it out for a while, then I could just reinstall the regular xpdf which would remove the conflicting xpdf-noask.

ConnorBehan · 2012-06-11 04:49:03

If you plan on changing the code more than a few times, don't use any scheme that would require you to rerun ./configure && make && make install - this will take forever. Instead figure out what the relevant binary is, for example /usr/bin/xfwm4. The "built" version of this will probably be under a subdirectory called ".libs" in the source directory. When you change something, only rerun make. This will be quick since it only rebuilds what you changed and then copy the file from .libs to /usr/bin.

Arch Linux

#1 2012-06-09 15:34:11

contribute to the open source community

#2 2012-06-09 16:35:45

Re: contribute to the open source community

#3 2012-06-09 16:59:16

Re: contribute to the open source community

#4 2012-06-09 17:42:28

Re: contribute to the open source community

#5 2012-06-09 17:53:28

Re: contribute to the open source community

#6 2012-06-09 19:32:30

Re: contribute to the open source community

#7 2012-06-11 04:49:03

Re: contribute to the open source community

Board footer