On Wed, Dec 19, 2007 at 03:24:28PM +0100, Fredrik Thulin wrote: } 1. What is the purpose of these patches? I'm guessing that what you want } to do is being able to include the 'yxa' application elsewhere? I'm packaging the stack as a library application separate from the real applications. The applications now include the yxa stack library application. In this way you have more flexibility in release handling, you can manage the stack itself seperately from the individual applications. And yes, if I build an application using the stack I can create a release package which does not include other applications. This allows you to use the SASL application more effectively.
I always build systems following the "Embedded Systems User Guide" [http://erlang.org/doc/embedded/part_frame.html]. This is how to run an Erlang/OTP application to take full advantage of it's non stop nature. To coax Yxa into this framework I configured with: ../yxa-src/configure --prefix=/export/home/otpuser/lib/erlang \ --sbindir=/export/home/otpuser/sbin \ --sysconfdir=/export/home/otpuser/etc \ --with-mnesiadir=/export/home/otpuser/db That gets you close anyway. To do it properly however what needs to be done is to use SASL to create a release package and install it on the embedded system. So now I have added a 'make packages' target which uses systools:make_tar/1 to create release packages of each of the applications. You then install a release package on the embedded system with the SASL application release_handler (e.g. release_handler:unpack_release/1). Unfortunately systools can't handle the non-standard directory heirachy in the Yxa build environment. It works however it will complain about missing source files and they won't make it into the release package. My changes to create beam files in ../ebin helps a lot but the subdirectories (e.g. transportlayer, event) won't be found. Moving all the .beam files into one ebin does however allow the SASL application systools to find them and sucessfully build a release package. Otherwise it all has to be done manually. } 2. Can VSN's be of the form 1.0pre1? PACKAGE_VERSION have at least in } the past been set to such things The Vsn attribute of the application resource file is a string() so it's acceptable. Whether the code loader can figure out which version is higher when more than one is installed is another matter. It does this by comparing the directory names in the code path and choosing the one with the "highest version number". It'd be better to stick to the point system (i.e. "1.0.1"). } 3. The patch of yaws/src/yxa_yaws_util.erl seems out of context, and } also incorrect? } } 4. Why does the eventserver.app-in have "{included_applications, [yxa]}" } commented out? Mistake or something making it special? Oops. Ignore the last set of patches. I will follow up right now with a new complete set and instructions for use. } 5. Is there a point in changing the order of the SUBDIRS in } src/Makefile.in from their current alphabetic order? Yes, that was necessary to satisfy dependencies. -Vance _______________________________________________ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
