Library list not compatible with Windows version

[Jeff]

MacBook, 10.6.5 bzr 2685 downloaded binary

Working on a design originally created in Windows KiCad (Wine on Mac really), MacOS version does not find libraries that are of the form somedir\somepart.lib. It reports those libraries as "not found" when the design is opened.
In the .pro file the "\" is represented as "\\". Manually editing the "\\" to "/" does work.

At first test, it does appear that the Windows/Wine version (bzr 2356 stable) will work with "/" as well as "\\". Unfortunately that works against getting casual users on Windows to switch to Mac.

[Dick Hollenbeck (dickelbeck)]

> Unfortunately that works
> against getting casual users on Windows to switch to Mac.
Your last sentence is not making sense to me.

Backing up, it is somewhat unusual to have Wine configured in such a way as
to have paths in Wine match paths on the host. So for example:

In Wine I might have:

E:\pathtofile\filename.txt

On the host I might have:

/longerpathtofile/filename.txt

So if I merely argue for a change in storage of the *.PRO file, say using /
always, does this really accomplish anything in the general case? For it to
be effective, would not the remainder of the paths and filename also have to
match?

I have no objection against switching to '/' in all stored pathnames, but
only if you can make a case that that actually solves problems. Then you
might get a patch accepted if you post one.

Dick

[Jeff (jkaskey)]

Patch is way outside my range of ability, I'm just a user posting the occasional bug.

The issue is:

Someone starts a schematic in Windows (in my case it was in Wine, but the effect is the same). They will create a .pro with "\" style paths for the libraries.

Then, they share the database with someone working on a Mac. No reason they should not be able to do so, assuming the (relative) paths are the same. That is, if they have built a compatible environment. You would expect to do this if you were sharing design tasks among more than one person, or if one person worked in more than one environment. In my case, I have native OSX and Wine at home, and a Windows system at the office. I'd expect to be able to move comfortably among them, and except for this little issue, KiCad allows that nicely.

My last sentence in the original post refers to yet another case where a Windows user simply want's to make the jump to a Mac environment, which is really a subset of the other use cases.

If the design starts on a Mac, going back and forth appears to work fine, at least using my Wine environment (I have not started using the "true" Win environment yet). So apparently Windows works with either "\" or "/". But if it starts in Windows, the Mac does not understand the "\".

In terms of other paths in the .pro file, what you say is probably true. Since I am only using eeschema, the only paths I see are related to the schematic parts libs.

Overall, I would agree that this is a small thing, although I suspect it is also a small change. And it gives bragging rights to "full Windows/Mac/Linux interoperability" which seems like a useful selling point as more people move between platforms.

[Jeff (jkaskey)]

Correction: at the top I said re Wine "...but the effect is the same." I do not really know that, having not run under native Windows. So take with grains of salt.
-J

[Jeff (jkaskey)]

In terms of why the Mac and Windows versions should be compatible, I'll note that the install.txt file says:

"Kicad binaries exists for Linux and Windows (XP, 2000, Vista)
Files (schematic, boards, libraries) created on both systems are fully compatibles."

The statement does not include OSX, but it seems like that's the direction KiCad is taking.

[Dick Hollenbeck (dickelbeck)]

Cross platform compatibility of data files is a goal that we all share.

Can you post the problematic *.pro file as an attachment, then a developer
with time can track down something specific.

Basically it sounds like the code needs to swap \ out for / before it saves
any path-filename to the *.pro file.