If I understand your model correctly, you're doing something like this:

• Create a set of files for an app in one directory, tailored to a given OS
• Create a symink to that first directory, where you'll put a version of the app for some other OS
• Run "presto" on the symlink, so that files known to be "common" are populated in the latter directory as links, and files expected to be OS-specific are populated as copies of the originals
• Edit the copied set of files in some way to make them appropriate to the latter OS.

If that's it in a nutshell, some folks might feel more comfortable with the "common" vs. "OS-specific" distinction made more explicit -- e.g. with a directory structure like:

 my_app/
   common/
   linux/
   mswin/
   macosx/
[download]

and an "installation" process that simply takes all the files from the "common" directory plus all the files for a given target OS, when setting up an operational copy of "my_app" on a given machine. This gives you more reliability as well as flexibility -- OS-specific files don't need a specific file name pattern that you have to memorize, and there could even be a different number of files to install, depending on the OS.

As for using hard links rather than symlinks, they are intrinsically cool, but they also may pose a hazard in your situation. Hard linking, which applies only to data files (not directories), is a matter of creating a second (third...) directory entry (in the same directory or a different one) that references the same inode on a given disk volume. Deleting a hard link means deleting a reference to the inode, and like perl data, when the last reference to an inode is deleted, its disk space is freed for re-use. The tricky thing is that a hard link is really just another directory entry pointing to an actual data file -- it's impossible to know that hard links are being used if you aren't specifically watching for them and paying really close attention.

In your case, the hazard comes with possibly forgetting the distinction between an OS-specific file and a common file. If you decide to edit a hard-linked file in "myapp.win", you are actually editing the same disk blocks referenced by that file name in the other "myapp" directory as well. If the edit makes the file OS-specific, the other version of the app breaks, and if you didn't keep a truly separate copy of the original file, you have a problem that may take a while to fix.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.