fxload source organization
OK, the first hurdle. How to organize the source and Makefiles for compiled programs.
My inclination here is to create under admin/ the src/ directory and put fxload under that. I can make a Makefile in the src/ directory that builds all the directories, and a Makefile in fxload that builds the fxload program. This should work out well enough as all compiled programs can be put under src/.
I predict that the next puzzle will be how to organize the install process. So far, it looks like a bunch of copies and hand-made directories, unless you are using the .spec file. Should I stick with that and update the .spec file appropriately?
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. [email protected] But I have promises to keep, [email protected] and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines
My inclination here is to create under admin/ the src/ directory and put fxload under that. I can make a
Makefilein the src/ directory that builds all the directories, and aMakefilein fxload that builds the fxload program. This should work out well enough as all compiled programs can be put under src/.
Well, I chose "admin" originally for administrative scripts, with etc/ and sbin/ directories to match the conventional installation points.
The admin/debian subtree doesn't quite fit in with that scheme, nor does the manpage that's at the top level rather than living in usr/man/man8 (and hmm, fxload should get one of those too).
Still, I unless we create a new organization for things that need to be compiled, I'd like to see locations of the compiled programs match conventional install points. So for example maybe usr/sbin/fxload.c (and usbmodules.c, pcimodules.c) would make more sense.
Quoted 4 lines
I predict that the next puzzle will be how to organize the install process. So far, it looks like a bunch of copies and hand-made directories, unless you are using the .spec file. Should I stick with that and update the .spec file appropriately?
Or add a "make install" target to the makefile.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · [email protected] said:
Still, I unless we create a new organization for things that need to be compiled, I'd like to see locations of the compiled programs match conventional install points. So for example maybe
usr/sbin/fxload.c(andusbmodules.c,pcimodules.c) would make more sense.
Except that each individual program is rarely a single C source file. gflashd (er, fxload) is two source files, a readme and a makefile, and it will surely grow as various kitchen sinks get added. I really doubt you want all that piled into a flat sbin directory.
OK, so it's a good thing I asked. How 'bout create under the sbin directory a directory for each compiled program, whereas scripts can be edited in place as files as they are now. For example, I can make admin/sbin/fxload as a directory and populate it with the source and makefile for fxload. Then I can add into the root makefile the needed fiddly details to cause that to be compiled.
The spec file can be made smart enough to do the install of the compiled binaries in the subdirectory. Will this jive with the debian way of doing things?
Quoted 1 line · [email protected] said:
Or add a "make install" target to the makefile.
Good idea. I can tackle that as well once these other issues are dealt with.
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. [email protected] But I have promises to keep, [email protected] and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · [email protected] said:
subdirectories can work, I've worked with source trees like that. though methinks /sbin is wrong for any of these programs, they're not classic "single user mode binaries".
It's OK for the install to distribute sbin/ files to /sbin/ and /usr/sbin on the target machine as is appropriate.
So here's another idea. Try this on for size:
I still create an admin/src/ directory and put under that directories for compiled programs. These programs compile their binaries into the admin/sbin directory, or admin/lib if it ever comes to that. The install then would be able to find the things it installs in the sbin/ and etc/ directories as now.
I think it is OK to have the src/ directory as an exception. This to some degree mimics the layout on a target system anyhow, that would have a /usr/src directory.
Signature · 11 lines
Steve Williams "The woods are lovely, dark and deep. [email protected] But I have promises to keep, [email protected] and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel