>From: Patrick Dills <address@hidden> >Organization: UCAR/COMET >Keywords: 200407020423.i624NgaW002282 McIDAS-X build Hi Patrick, re: changing runtime link >Thanks...got it. 04' code seems to be running now. re: local modifications >I think you mentioned this a while back, but is there a way then to avoid >using the fx.sh script and then just doing a 'make install' so that only >those (core MCIDAS-X) files with the latest time stamp are pickup up for >re-building? Yes. There are a couple ways to do this: - make modifications/additions as 'mcidas' in the mcidas2004/src directory - setup a local build directory structure in which you do builds or create modified code If nobody else uses McIDAS, you could proceed with the first option without too much worry. The only problem is that your additions/mods get "lost" among the hundreds of source files that make up the McIDAS distribution. If you are modifying code in the distribution, you would need to remember to save your mods so you wouldn't lose them in the next McIDAS upgrade. And, you could simply use make to build the newly modified routines. My comment was that a 'make install.mcxall' was overkill since it is likely that you would only be changing a single routine at a time. If you were using Vendor (i.e., Sun) compilers, there would be no need to do the install step since the hard link between the executable created in the mcidas2004/src directory would result in the version in the mcidas04/bin directory being updated. When compiling with gcc/g77, however, the executable in the mcidas2004/src directory is deleted and then remade, so the link is broken and you end up with different files in mcidas2004/src and mcidas04/bin. In this case, the quickest thing to do is: make blah.k rm ~/mcidas04/bin/blah.k ln blah.k ~/mcidas04/bin This takes a couple of seconds while a 'make install.mcxall' will take several minutes, especially on gizmo given how slow it is. Now, if you had a separate build environment, you could simply run 'make' followed by 'make install' and this would be fast since, presumably, you would only be building one or a couple of executables. Those would be linked or copied to the ~mcidas/mcidas/bin directory and your PATH would have to be adjusted to include that directory _before_ the ~mcidas/mcidas04/bin (or, since you are using the runtime link approach, before the ~mcidas/bin direectory). >I'm thinking about tackling Marianne's MSG server >code...but of course that would fall outside the core MCIDAS-X domain. And that is why it may be a good idea to setup a separate build tree for your code. >Sounds like a worthwhile effort since I have quite a few new and modified >apps waiting for resurection also. Any pointers on how to proceed? I can help you do this today when I come over to talk with you and the fellow from EUMETSAT about Marianne's server. >Is any of this covered in the "programmer's guide" by chance ? Yes. I would recommend a slightly modified approach. We can talk later today. I will be coming over at 11 am to chat. See you then. >continued thanks Tom, No worries. Tom -- NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publically available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.