search

ucscGenomeBrowser / kent

UCSC Genome Browser source tree. Stable branch: "beta".
http://genome.ucsc.edu/
Other
219 stars 89 forks source link

making Centos74 happy #14

Closed psteinb closed 5 years ago

psteinb commented 6 years ago

Hey kent developers, I worked quite a bit on your build system for @MichaelHiller. The makefile of each binary (e.g. in src/hg/) appear rather inflexible to me. Some link against libraries they don't even need. I applied tons of quick fixes. Not sure if they are too specific. In any case, as this is a server app, why do you prefer linking against static libs, e.g. here? I thought that kent is aimed at webserver workloads. Wouldn't it be better to dynamically link to be able to upgrade the underlying runtime environment? Just wondering.

NullModel commented 6 years ago

Good Morning Peter: Can you direct me to the centos version where the existing static linked binaries do not function ?

Of course, your issue here touches upon a much discussed subject over the years. It somewhat depends upon what the intended audience is for the source tree and the resultant binaries. We have tended to side with the users who do not have the ability to build the source tree, but just want to run one of the kent commands. The static linked binaries helps with that difficulty.

See also: http://hgdownload.soe.ucsc.edu/admin/exe/linux.x86_64/

I'm also curious about the odd locations you have changed in your alterations. Many of those files you touched have nothing to do with either the web browser binaries, or the user apps binaries. A lot of that was obscure one time experiments with some function, often obsolete after the experiment was concluded. That is one reason why those makefiles you touched have no relationship to current practice of our makefile structure. Most of our current makefiles are simple three line items with no specifics, e.g.:

kentSrc = ../../..
A = pslUniq
include ${kentSrc}/inc/userApp.mk
psteinb commented 6 years ago

Good Morning Peter: Can you direct me to the centos version where the existing static linked binaries do not function ?

Sure thing: I am trying to build kent on centos 7.4.1708. But please don't bother too much with this fact. I am debugging environment overrides of MYSQLINC and MYSQLLIBS as well which I found. These were historically inherited locally. So let me get them out of the way first.

Of course, your issue here touches upon a much discussed subject over the years. It somewhat depends upon what the intended audience is for the source tree and the resultant binaries. We have tended to side with the users who do not have the ability to build the source tree, but just want to run one of the kent commands. The static linked binaries helps with that difficulty.

See also: http://hgdownload.soe.ucsc.edu/admin/exe/linux.x86_64/

Unfortunately, this is not an option to me, as my client added some private code ... reusing the library infrastructure inside kent. I do see better now what you are targeting with the Makefiles then and why you prefer static includes. However, I feel that the build system is overly coarse grained (applying one-fits-all global variables to all targets irrespective of their need) and dependency management is quite flawed or even missing.

I'm also curious about the odd locations you have changed in your alterations. Many of those files you touched have nothing to do with either the web browser binaries, or the user apps binaries. A lot of that was obscure one time experiments with some function, often obsolete after the experiment was concluded. That is one reason why those makefiles you touched have no relationship to current practice of our makefile structure. Most of our current makefiles are simple three line items with no specifics, e.g.:

kentSrc = ../../..
A = pslUniq
include ${kentSrc}/inc/userApp.mk

Thank you for the explanation. I see the situation more clear now. I just followed the readme and started with a plain make (after building the libs) inside the src folder. That was a mistake, I think in retrospective. It would be nice, if those experiments you mentioned, would be removed from the main build targets alpha, beta and all inside src/makefile. I feel these 3 are the main targets in use. We use alpha mostly AFAIK.

All in all, I have no problem, getting this PR rejected. It would be nice though, to see the kent src in a cleaner state (experiments removed from main targets). The setup of the makefiles could use some upgrades too or a rethinking if GNU make is really the right choice, given that kent exposes quite a hierarchy of source folders (GNU make was never good at recursive builds). Simply put: Don't forget the users which want/need to build kent.