search

rcedgar / muscle

Multiple sequence and structure alignment with top benchmark scores scalable to thousands of sequences. Generates replicate alignments, enabling assessment of downstream analyses such as trees and predicted structures.
https://drive5.com/muscle
GNU General Public License v3.0
188 stars 22 forks source link

makefile is nonstandard and redundant #3

Closed joelb123 closed 3 years ago

joelb123 commented 3 years ago

The default Makefile uses ccache, which is nonstandard and rarely installed on most modern systems. This is the first problem that someone who wishes to build the code will encounter Makefile_osx does not have this issue, although it does not build for me on up-to-date OSX with the standard clang-based Apple developer tools installed. That's a different issue, though.

There are many lines of rules for building cpp object, all of which can be replaced by the simple standard rule:

%.o: %.cpp $(DEPS) $(CPP) -c -o $@ $< $(CPPFLAGS) muscle5: $(OBJS) $(LNK) -o muscle5 $(LNKOPTS) $(OBJS) if one does the standard practice of making object files in-place.

rcedgar commented 3 years ago

ccache good catch, fixed. Makefile issues noted, but unlikely to be changed any time soon. As with the version counter header issue, this reflects that behind the scenes is a very large, complex code base which is under on-going development mostly in Visual Studio/Windows under a parallel VCS. Exporting selected chunks of this code to git[hub] is a non-trivial exercise. The Makefile is generated from the Microsoft .vcxproj file by a script. In the unlikely event this repo becomes a collaborative open-source project, then this would be worth revisiting.

joelb123 commented 3 years ago

Well, then are you inclined to accept pull requests? I can easily generate them.

I have also found that "-std=c++11" is needed and "-static" needs to be deleted for building under my gcc "11.1.0". You will likely find that what you think was built completely statically will require the same version of gcc to be used, and I'm guessing you're building on a fairly old gcc:

/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/libgomp.a(oacc-profiling.o): in function `goacc_profiling_initialize': /var/tmp/portage/sys-devel/gcc-11.1.0-r1/work/gcc-11.1.0/libgomp/oacc-profiling.c:137: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Again, I find you quite fast to close issue that aren't really closed.

rcedgar commented 3 years ago

Joel -- How would I know if an issue is "really" closed? Again, please note that I have very little experience with git or the conventions of collaboration on github. In general, I would be inclined to accept a pull request if I understood the update. If it's for the Makefile, I would probably decline a pull request because I don't see a problem with it (except for ccache, now fixed), and it will revert to my automatically generated format the next time I post a significant code update. I understood that you had to change some gcc command-line options, though this seems trivial to fix and AFAICS you would be changing the gcc version dependency rather than making it more robust against gcc version. Re. static linking, I do not link to any third-party libraries because they tend to cause dependency nightmares. I have been posting statically-linked binaries for popular software such as muscle and usearch for the past 15 years and have never heard of a shared library dependency problem. Therefore I have good reason to believe the linker warning about dllopen can be safely ignored.