Simplified install

[n8vi]

Any thoughts of splitting off a simplified pasm and lib release that you can just make install, like https://github.com/n8vi/bbb-pru?

[jadonk]

Yeah, it is on my immediate to-do list to create a 'make install' for what gets placed in the Debian package. I'll look at how you did it unless you feel your implementation is already clean and provide a pull request.

[n8vi]

I'm curious if a lot of users are actually cross-compiling. I'm certainly not, my ARM is plenty fast and it's way more convenient to compile where you can run and test. But this weekend I can probably fork your actual git project and whip you up a quick makefile with install target that detects if you are cross compiling or not and Does All The Things.

[fhunleth]

FWIW, I only cross-compile.

There are basically two routes that make my life easy. The first is to use autotools since that just works for me. The second is to use make macros when referencing the C compiler so that I can override them (many people use CROSS_COMPILE or just reference the C compiler via $(CC)). I can certainly make a pass on the Makefile to test out cross-compiling.

[n8vi]

I'm not really familiar with actually making things with autotools, though probably that's something I should learn at some point. I just figured I'd look at the output of "uname -m" and not cross-compile if I'm on arm, perhaps with an environment-based option to override this behaviour.

[ghost]

My threshold for switching to autotools is whether I have to deal with shared libraries. If yes, then autotools. If no, then simple Makefile. If this can be kept as a simple Makefile, then trying not to make it too smart usually helps me. I'd rather just pass in the CROSS_COMPILE prefix or override CC than have the makefile run "uname". The reason is that the name of the cross-compiler can change. The issue of running the host's compiler rather than the cross-compiler by accident is not a big deal, since it's so easy to detect.

[fhunleth]

Hi all - just saw the new Makefile get pushed up. Thanks for adding the CROSS_COMPILE tag. Looks good on its own, but there is some weirdness for me when I integrate the project with Buildroot. Buildroot requires that either you build everything for the host or everything for the target. Since the top level Makefile builds the loader for the target and pasm for the host, I can't use it in the Buildroot integration. Of course, I'm going to have this problem with any top level Makefile. (Sorry - this issue didn't occur to me earlier)

Given this thread, and a couple others, I'd really like it if pasm and the loader could be split into two projects and allowed to progress separately. Their current coupling seems to cause issues that I think could be avoided. If it helps, here's what an autotools version of pasm could look like: https://github.com/fhunleth/am335x_pasm. The Makefile for the loader looks to be in better shape for splitting off into its own project.

[jadonk]

I'm comfortable with having a couple of different Makefiles if the components are going to land in different packages, which makes sense that they should be after all. For the Debian packages, we'll likely turn am335x_pru_package into a meta-package with am335x-pru-assembler, am335x-pru-uio-loader, etc.

I'm not comfortable with breaking this into separate repositories and losing the history.

[jadonk]

Can I close this issue?

[n8vi]

Oh, I think so. Sorry I didn't see your question until now, github just thought to notify me about it.