Re: Exportability of EDA industry from North America?

Are you sure? The RedHat site gives no hint that you can run the current RHs without paying. The free distribution is FCx, which is different.

BTW,

formatting link
sells tuxedos...

:)

Rick

Reply to
Rick Thompson
Loading thread data ...

In sci.electronics.cad Chuck Harris wrote: : Hi Stuart,

: Ok, I have figured out what's going on. If you cd to the directory : that the RF_Amp is in, and then invoke gschem, Open page and select : the MSA-2643.sch drawing, everything works the way you all probably : expected it to.

: However, if you are in some miscellaneous directory, and invoke gschem, : Open page, and wind your way through the directory structure until : you find the MSA-2643.sch drawing, and open it, then you get a schematic : with blank spots where the transistors should be.

: So, what is happening is you only read the gafrc file for the directory : that you are in when gschem is invoked.

: What to do? It doesn't seem too unreasonable for a person to be able to : start up the geda tools from any old directory they happen to be in and : browse their way to the design files using open page, and expect the : right thing to happen.

: It seems to me that a reasonable solution would be to have gEDA tools : read any appropriate rc files found in the directories where you open : a new, or old page. I am unsure what would be the best solution for : opening a new page in a new empty directory. Perhaps if the directory : is created from within the gEDA tools, the directory should be prefilled : with an rc file from some template directory?

Hi Chuck --

OK, this is a user education issue. Sorry!

Loosely speaking, gEDA has three sets of RC files: One system wide, one for you as a user, and one living in the local project directory:

  • The system one lives in ${PREFIX}/share/gEDA, where ${PREFIX} = wherever you stuck your gEDA stuff when you installed the dist. This one holds most of the path info about where symbols live. It is always read in upon program start-up.

  • The user one should live in ${HOME}. You can use this for customizations you would like to use across all your projects. (Like remapping the key actions, or screen colors.) Gschem tries to read it upon program start-up, but only warns you if it can't find it.

  • The project one lives in the project directory where the schematic files are stored. This one is used for customizations local to that particular project. (Like storing local symbol files, or other project-specific stuff.) Gschem tries to read it upon program start-up, but only warns you if it can't find it.

When gschem opens up, it tries to read all three. However, if you run gschem on a file living in another directory from the one you are in, then it doesn't see the project-specific RC file.

In the case of the RF_Amp example, the gafrc file lives in the RF_Amp project directory. I am not sure that making that project-local RC file work when reading the .sch file from outside that directory is a good idea. The vision is that you put project-specific customizations into there. That means that you run gschem while working out of that directory.

There is a mechanism for specifying which RC file to load using the -r flag, but it doesn't seem to follow file paths like "./sym" correctly (I just checked). I can file a bug report on this.

I agree that the nice thing to do is to have all schematic open correctly from everywhere. The way to do that is to have gschem deduce the project directory from the path to the file being opened, and then open the corresponding RC file. But what if a user then opened two files in two different directories? Which RC file to open? Both? What if they conflict?

Therefore, this question needs some further thinking. Meanwhile, it does raise the question of bullet-proofing the examples for newbies. I'll think about that.

Stuart

Reply to
Stuart Brorson

They think they can, because they can. It's pretty much that simple. People pay them. People want Aunt-Tillie-Ready stuff, with the security of a Linux kernel, so they pay the Redmond^H^H^H^HHat people to do all of their configuration for them.

I paid $40.00 for the 4-disk Slackware set, and I'm quite happy with it, and it's downloadable for free. Actually, the only reason I actually paid for it is because I want to support Mr. Volkerding and the whole Slack mystique. ;-)

You do have to know enough about your computer to be able to manage it, however. Or be willing to learn.

As far as "The EDA vendors only support RedHat", that could be because Redmond^H^H^H^HHat is the only distro that _needs_ vendor support.

I'll be installing gEDA from source Real Soon Now, and I'll give a full report.

Good Luck! Rich

Reply to
Rich Grise

I had meant

formatting link
but I got it mixed up with
formatting link
and ended up someplace in the muddle.

But they don't seem to have RHEE anyway.

I am not sure how redhat could restrict the enterprise edition, being as it is based on GPL'd code. Anyway, I am heading in the Debian direction. It is as stable as you want it to be.

-Chuck

Reply to
Chuck Harris

I cannot honestly say that I have done a good job working my way throught the documentation. I only have a little time each day to play, and then I seem to tend to just jump in...

[snip]

Spawn a version of gschem for each file, and use the corresponding project rc file for each incantation?

In any case, I believe the only thing the gEDA suite should take from the place it was invoked is the home directory root. The gafrc project file must be correct for the file that is currently being displayed on screen.

-Chuck

Reply to
Chuck Harris

All in all, the installation went ok once I ironed out two small problems. I think you will have fun. The suite looks quite competent.

-Chuck

Reply to
Chuck Harris

I've got no problem with configuration. I've got RH7.2 on one machine and FC2 on another, with various different combinations of libc, gcc, gdb, gtk, and all the rest of it, without problems. My issue is with all the half-arsed beta front-end stuff that the hackers put out with every distro and every release of that distro. Just one example: the help system on my RH7.2 never worked, despite a clean install, because of some Nautilus configuration problem that I couldn't find. How can you *possibly* ship a leading distribution with this level of incompetence? Bill Gates must be laughing all the way to the bank.

The great thing about the new RedHat is that they might, finally, bring a level of professionalism that could consign all this nonsense to history. But, of course, without an annual subscription. Bill Gates didn't need it, after all.

Synopsys, Cadence, and Mentor aren't stupid; they turn over nearly $3B between them. I don't know why they supported it historically, but RH7.2 was widely accepted. If that's good enough for them, then that's all the encouragement I need. Linux badly needs some standardisation; having so many distributions may be great for hackers, but it could kill Linux for serious work.

BTW, I used Debian for a year and wasn't impressed.

Rick

Reply to
Rick Thompson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.