Building for dev

[Baylink]

I see two conflicting thoughts:

1) Don't build from source, it's a major (not really supported) pain in the ass.

2) If you want to contribute, we'll be happy to take your pull requests.

I'm having a hard time reconciling those. Any thoughts from people who *are* active devs?

[knight-of-ni]

As an active developer of the zoneminder project, I speak from daily experience when I say that 99% of the time you don't ever have to build from-source. I can't remember the last time I did a traditional cmake, make, then make install.

Think of zoneminder like getting a free car, except you have two choices.

You can be given the whole car, which you can customize to your liking, or you can be given all the parts to assemble the car yourself. Most will choose the former because they recognize the large amount of work required to accomplish the latter. Even those that might want to modify the car after the fact, don't necessarily have to build the car themselves.

Keep in mind, I'm not knocking those who want to go down the latter path simply for the experience. I get it.

Just to give you just one example of why we discourage building from source, the authors of Perl's make::maker module no longer even support a make uninstall. Can you believe it? I still think that sounds crazy, but sure enough.... if you try to make-uninstall a zoneminder from-source installation, all the zm perl modules are left on your system, with no error generated.... and that is just begging to mess up a new, future version of zoneminder. The industry has transitioned to package based installations, and so have we.

I'm sure you have seen the links I have posted in other threads indicating how to build a zoneminder package based on a release or latest master branch for popular redhat/debian/ubuntu distros. You should try them. It's really very easy.

With all that said, what I really think you are doing is trying to find a way to contribute, and I thank you for that.
Where I recommend you start is to learn github if you have not already. Clone the zoneminder repo, create a new branch, make a trivial change to it, and then push it to your fork. I have documented this process here:
https://github.com/ZoneMinder/ZoneMinde ... l-Requests

When a pull request is generated on our site, we have an integration with a third party site called Travis CI, which will immediately build that change and verify it compiles. If you want to play around, you can even enable Travis CI in your own fork of zoneminder. It's just a few mouse clicks under your github settings.

If the pull request is merged into master, we have another integration which will rebuild a new set of zoneminder packages within 24 hours containing that change.

Sometimes, especially when you are writing C which must be compiled to test, you might want to do that locally before you publish it. To do that, you follow the documentation for building a zoneminder package for your distro. The only difference, you will be working out of your local git branch, rather than master.

[Baylink]

So the package installs install all the source, and PRs generated from those installs will apply against trunk?

That's not what I would have expected...

[knight-of-ni]

Negative.

The first thing you should do is download the zoneminder source code from github:
git clone https://github.com/ZoneMinder/ZoneMinder

You also need to create an account on github.com and then fork the project.

To go further, make changes, etc. review the link I posted previously.

Keep in mind, that anything you do on your local disk has no affect on the project until you 1) push it to your own fork on github 2) generate a pull request to get it added to the zoneminder project, and 3) someone approves it and merges it into the master branch

Consequently, you can't really break anything permanently so feel free to experiment until you are used to using git.

[Baylink]

I'm now very confused, as it sounds as if you've told me both not to build it from source and *to* build it from source (pulled from github). Which part am I missing here?

(And for the record, this won't be my first rodeo with github, while I don't approve of its overcomplicated interface, I have used it enough before not to approve of its overcomplicated interface. )

[knight-of-ni]

I think you misunderstand the difference between building from-source and building a package.

from-source build
The source code is downloaded by the end user to the local system as a tarball, cloned from a git repo, or some other method.
The end user then proceeds to call cmake (or configure if using autotools), then make, then make install. In that order.
These steps will configure the make files, compile the program, and then install the software onto the system, usually under /usr/local
None of the installed files are tracked by the system. Dependencies are checked only during build time.

(local) package build
The source code is downloaded by the end user to the local system as a tarball, cloned from a git repo, or some other method.
Instead of calling cmake make & make install, packaging scripts are called instead which will build zoneminder in a controlled chroot style environment.
Technically, yes, the packaging scripts are calling cmake, then make, and then a special form of make install, but this is completely shielded from the end user. When the resulting package is installed, all its files are tracked by the os'es package manager.

So when I say clone the git repo and then build your work into a package (using the documentation and scripts we have written for you), I am talking about the latter. This is all documented here: http://zoneminder.readthedocs.io/en/lat ... index.html

[Baylink]

Ok, then I'm still missing something, as I don't see any step in that process that leaves me with something where I *can* extract my changes as a pull request.

I've been a programmer for 25 years or so; the large brush strokes, I have.

If I build a package and install it automatically, then it's *installed*; I don't have any chance *between* git clone and build to make changes.

I'm not so foolish as to make changes *to an installed package*, that I expect to be portable.

[rockedge]

I have done this and posted the package for download for Puppy Linux Tahr 6.0.5 (Ubuntu 14.04) specifically built in this manner,
It is in the Puppy Linux .PET file format and one click it installs everything and creates the users for mysql and apache sets up the database and db user/password and as soon as one opens a browser and goes to localhost/zm there it is RUNNING, The process is to install Apache and mysql/mariadb with PHP and PERL then insure all the dependencies and libs are present then I compile ZM...but at the make install stage I change it to new2dir make install and then I have a complete PET package of zoneminder. It is really a chroot file system set up with all the components to run ZM that is built into the package.
Using the PET package the Puppy Package Manager can track the installation. I have also made a 265 meg ISO of a Puppy Linux OS with ZM 1.30.2 that runs in RAM and can be run as a LiveCD with save file/folder and can update from iconner PPA stable or master branch interchangeably.

There wasn't any interest in what was made, even though the 1.30.3 and 1.30.4 PET versions run perfectly as does the LiveCD iso.....
so I do not maintain it and build away now for experimental purposes and to advance other ZM code.

viewtopic.php?f=6&t=25912
http://murga-linux.com/puppy/viewtopic.php?t=109433
http://murga-linux.com/puppy/viewtopic.php?t=110419
http://www.murga-linux.com/puppy/viewtopic.php?t=35507

[Baylink]

I believe that you are answering the question "how do I download it and build a package?", not my question, "how do I download it and then *make changes before building a package* *such that I can submit the changes back Upstream*?"

Both of those starred Clauses are critical to my understanding what Andrew is trying to tell me I can do.

[knight-of-ni]

Ok, then I'm still missing something, as I don't see any step in that process that leaves me with something where I *can* extract my changes as a pull request.

https://github.com/ZoneMinder/ZoneMinde ... l-Requests

[Baylink]

Yup, I looked at that.

But I don't see how that integrates with "always install from a package".

I can't work on that cloned repo *unless it's installed and running*, and my PR'd changes *have to come from the version I have installed and running*, or they cannot be guaranteed to be valid, correct?

And there's package-maintainer thinking involved in "build a package from a source tree", right? Not just a click?

I'm sorry, Andrew, but I am still Just Not Getting It.

[SteveGilvarry]

Let me have a go.
Fork in github, get that local, should be on master, then build a package locally from that local content. Install that and you have zm master.
The checkout -b "Some Name", will create a new branch under where your changes will be source controlled. (New branch so you can still update master while you work). Make code changes, commit them locally, and build package from local content. Once happy push them from local repo to your GitHub repo and the PR will be from that new branch in your GitHub repo, with the commits that you made, packaged and tested locally.
Now in saying that I sometimes do active development on a VM with an IDE, in that instance I have generally installed from a package, then modified the cmake folders to match Debian package locations. Then the IDE lets me build, and debug. So building from source I do, but I then take those changes once pushed to my repo and build a package to deploy on a test server.
Ask on irc as most of those doing dev are on there.

[Baylink]

Okay, I followed that a little bit more closely, Steve, but the part I'm still stumbling on his this: the process of packaging a source tree for a given OS is something which, presumably, requires the smarts of a packager.

I've done that before: I know that it's non-trivial, since it is precisely the work which is supposed to be hard if one is trying to install from source.

Is it actually the case that packaging a source tree for a given distribution is much easier than I believe it to be?

[knight-of-ni]

The exact steps vary per distro, but if one is using Ubuntu, then building zoneminder into a package is as simple as executing:

Code: Select all

./do_debian_package.sh --snapshot=NOW --fork=baylink --branch=baylinksbranch --type=local

Where --fork & --branch are set appropriately

The do_debain_package.sh has what you have coined "the smarts of a packager". It does all the hard stuff for you and builds zoneminder the same way as the packages you can get from iconnor's ppa.

These steps for are all documented in the installation guide referenced earlier:
http://zoneminder.readthedocs.io/en/lat ... rom-source

There are corresponding instructions for redhat distros as well.

[iconnor]

Here's what I do, and what I do is both build packages and constantly test my dev work. Try to understand, we don't want users building from source. Dev's definitely should.

I have an alias set up in my ~/.bash_aliases that looks like this:

alias zm_cmake="cmake -DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_SKIP_RPATH=ON \
-DCMAKE_VERBOSE_MAKEFILE=OFF \
-DCMAKE_COLOR_MAKEFILE=ON \
-DZM_RUNDIR=/var/run/zm \
-DZM_SOCKDIR=/var/run/zm \
-DZM_TMPDIR=/var/tmp/zm \
-DZM_LOGDIR=/var/log/zm \
-DZM_WEBDIR=/usr/share/zoneminder/www \
-DZM_CONTENTDIR=/var/cache/zoneminder \
-DZM_CGIDIR=/usr/lib/zoneminder/cgi-bin \
-DZM_WEB_USER=www-data \
-DZM_WEB_GROUP=www-data \
-DCMAKE_INSTALL_SYSCONFDIR=etc/zm \
-DZM_CONFIG_DIR=/etc/zm \
-DCMAKE_BUILD_TYPE=Debug"


This is roughly equivalent to what a debian .deb package would use. So I clone the repo, do a zm_cmake && make
If I want to install it, I do sudo make install This overwrites whatever packages I have installed, but does so in the right way.
This does require you do have all the dependencies installed first, which is a huge pia, for which we propose that you use the package build scripts to automate for you. Or you can just keep retrying that command and installing the packages that it complains about until it finally succeeds.

So then if I'm working on the C++ code I go into src and can do make && make install and things like that. Same with /web.

When I get things working right, I make a package with the do_debian_package.sh and if that works, then I use that script again to make a release package.

The long and short is, if you are a dev, you do what works for you. If you are a user... stick to a package.

Welcome to ZM development! What are you working on?