|Summary:||ASTERISK-14692: [patch] Need makefile to do kbuild-like out-of-source-tree builds for Asterisk modules|
|Reporter:||Philip Prindeville (pprindeville)||Labels:|
|Date Opened:||2009-08-21 19:39:51||Date Closed:||2011-06-07 14:00:25|
|Environment:||Attachments:||( 0) Makefile.module|
|Description:||Linux modules have "kbuild".|
Apache modules have "apxs".
Asterisk needs something similar. Building a bundled distro (like Astlinux, for instance) means having two possible courses of action:
(a) have hairy "buildroot" makefiles that copy bits of source into the asterisk/ source tree, apply patches to the makefiles, etc. and hope that the next version bump doesn't break your patches and sources;
(b) have a way to build outside of the source tree with only the asterisk include files (i.e. the "apxs" and "kbuild" way).
Obviously, (b) would be a lot more robust and simpler to maintain.
Tilghman wrote the following makefile, and we've been copying it into our source tree (sigh) and using it. It works great. We'll swear by it.
We just would like to go the final step and have it be in the source tree permanently.
|Comments:||By: Kevin P. Fleming (kpfleming) 2009-08-24 12:59:55|
That Makefile uses much more than just the Asterisk header files; it needs an entire configured Asterisk source tree.
The installed Asterisk header files are *supposed* to be all that is needed to be able to build an out-of-tree module, with no special Makefile required. In fact, we do exactly that when building binary modules for our various commercial products... build Asterisk, install it, then build the out-of-tree module by just including the needed Asterisk header files.
Can you document something that does not work using this method?
By: Philip Prindeville (pprindeville) 2009-08-26 20:31:39
I think the operative parts here are "build Asterisk, install it, then build the out-of-tree module", especially the "install it".
In a cross-compilation environment, there's nothing to install (again, much like cross-compilation with Kbuild or apxs).
Yeah, you can probably set all of the required Make variables, and include all the right files and eventually figure it out yourself... but why? You set three variables with this file:
LIBS (which may be empty)
and you're golden. It would be hard to make it any easier than that.
By: Kevin P. Fleming (kpfleming) 2009-08-27 10:42:28
So if you are going to use a configured-and-built Asterisk source tree, then why don't you just use the same method that Kbuild does, and do something like:
$ make -C /path/to/asterisk/source MOD_SUBDIRS=`pwd` OTHER_SUBDIRS=
I just don't understand what the point of an additional Makefile is that cannot be installed (because it requires the source tree to be functional) and shouldn't be copied *into* the out-of-tree module source because the main Asterisk Makefile requirements may change, and it would get out of date.
How about you try to use the method I posted above, and if that fails for any reason we'll treat that as a bug that should be fixed. Would that be acceptable for your build needs?
By: Kevin P. Fleming (kpfleming) 2009-10-01 11:39:03
Were you able to try this method?
By: Leif Madsen (lmadsen) 2009-10-26 10:00:57
Pinging reporter for feedback.
By: Philip Prindeville (pprindeville) 2009-11-05 00:59:59.000-0600
zcat /home/philipp/pristine/dl/app_notify-2.0rc1.tgz | tar -C /home/philipp/pristine/build_i586 -xf -
toolchain/patch-kernel.sh /home/philipp/pristine/build_i586/app_notify-2.0rc1 package/asterisk-app_notify/ asterisk-app_notify\*.patch
Applying asterisk-app_notify-header.patch using plaintext:
patching file app_notify.c
make -j2 -C /home/philipp/pristine/build_i586/asterisk-126.96.36.199 MOD_SUBDIRS=/home/philipp/pristine/build_i586/app_notify-2.0rc1 OTHER_SUBDIRS=
make: Entering directory `/home/philipp/pristine/build_i586/asterisk-188.8.131.52'
Generating input for menuselect ...
make: *** No rule to make target `moduleinfo'. Stop.
make: *** [menuselect-tree] Error 2
make: Leaving directory `/home/philipp/pristine/build_i586/asterisk-184.108.40.206'
make: *** [/home/philipp/pristine/build_i586/app_notify-2.0rc1/app_notify.so] Error 2
What am I missing?
By: Tilghman Lesher (tilghman) 2009-11-05 15:19:17.000-0600
This is a feature request without a patch. It therefore does not belong on the issue tracker.
By: Philip Prindeville (pprindeville) 2009-11-05 15:44:01.000-0600
Since the work has already been done in the form of the Makefile.module attachment here... and I've tested it and confirmed that it works... why not commit it to the mainline tree in a subdirectory (doc?) as an example? Then it could be linked to from $(TOPDIR) ...
By: Philip Prindeville (pprindeville) 2009-11-05 15:44:36.000-0600
> This is a feature request without a patch. It therefore does not belong on the issue tracker.
Actually, you've already kindly provided the patch. :-)
By: Philip Prindeville (pprindeville) 2009-11-05 16:18:56.000-0600
Better yet, put it in contrib/
By: Tilghman Lesher (tilghman) 2009-11-05 17:34:00.000-0600
As Kevin noted in #asterisk-dev, if we were to do this, it would be as arguments to the standard Makefile, not a separate Makefile, so that the commands would never go stale. Hence, what is here does not fit the bill.
By: Philip Prindeville (pprindeville) 2009-11-17 15:04:57.000-0600
Ok, let's keep this open. I will try to work this into the top-level Makefile as suggested.
I'll come back with a patch when I have one.
By: Tilghman Lesher (tilghman) 2009-11-24 10:03:28.000-0600
Proposals without a patch are not kept open here. I have suspended the issue. You may reopen ONLY when you have a candidate patch.
By: Philip Prindeville (pprindeville) 2009-11-30 15:18:59.000-0600
Unfortunately there's no way to add a note without reopening the issue.
Was reading the commit comment on #204413:
Move Asterisk-addons modules into the main Asterisk source tree.
Someone asked yesterday, "is there a good reason why we can't just put these
modules in Asterisk?". After a brief discussion, as long as the modules are
clearly set aside in their own directory and not enabled by default, it is
For more information about why a module goes in addons, see README-addons.txt.
chan_ooh323 does not currently compile as it is behind some trunk API updates.
However, it will not build by default, so it should be okay for now.
you'd think that the same reasoning would apply to putting a helper Makefile for out-of-tree module builds would work, as that wouldn't be built by default either...
By: Tilghman Lesher (tilghman) 2009-12-04 00:05:37.000-0600
Re-suspending, per policy.