fxload source organization

fxload source organization

[Stephen Williams]

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?

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve@icarus.com              But I have promises to keep,
steve@picturel.com            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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: fxload source organization

[David Brownell]

> 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/.

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.

 
> 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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: fxload source organization

[Stephen Williams]

david-b@pacbell.net 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
> (and usbmodules.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?


david-b@pacbell.net 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.
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve@icarus.com              But I have promises to keep,
steve@picturel.com            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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: fxload source organization

[Stephen Williams]

david-b@pacbell.net 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.


-- 
Steve Williams                "The woods are lovely, dark and deep.
steve@icarus.com              But I have promises to keep,
steve@picturel.com            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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel