[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20040721: Unidata McIDAS-X v2004 build on gizmo (cont.)

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