Exportability of EDA industry from North America?

The use of LD_LIBRARY_PATH has been depreciated for years. I was rather perturbed when gEDA dredged it up and made me set it. It is a seriously bad idea to use it in a global way on any system.

Pkg-config does live on my system, but it does nothing interesting because there are no .pc files on my RH9 system. AFAIK there never were. I have compiled numerous packages, and gEDA is the first I have found that requires pkg-config. Further, your detection of gtk2 is the only package in gEDA that ./configure misses. Until I built my first version of gEDA, PKG_CONFIG_PATH wasn't even set on my machine. (I cannot prove it, but I don't think it is set by any RH9 system)

Again, your incantation of ./configure cannot find gtk2 on my system, but it has no trouble finding gtk+. When it decides it cannot find "gtk+-2.0" it checks for gtk+ (version 1.2something), finds it and goes along merrily.

I'm running a 666 MHz machine, and I waited several hours before I decided (mistakenly) that it was spinning its wheels. I tried it later, and let it spin until completion. I would guess that this installer bug increases the compile and install time by about 10 times.

I am 99% sure that there is some info in the installer's documentation that says if you install as root, it will automatically put everything in /usr/local/, and that includes the project files. I *know* I read that somewhere in gEDA's documentation, and it seems to behave that way with the ./configure type of install. I distinctly remember reading something that said you needed to give all users r/w access to the /usr/local/ directory tree. This is something that I do not want to have, so I have been doing my installs in user mode.

Don't be insulting, I had the previous version of gEDA working on my system before I tried to use the 20041228 install CDROM.

I have been using gerbv for years now. I had zero problems compiling and installing it.

-Chuck

In article you wrote: : Hi Ales,

: Ales Hvezda wrote: :> Hi, :> :> I usually like spending my free time working on the code rather than :> posting to USENET, but I want to address some of the points from the :> previous poster in this thread.

: Thank you, I appreciate your time. I would prefer not to use this : forum for detailed debugging, but since I started this, and have no : interest in performing a hit-and-run tar & feather job, I guess we have : to resolve the problems here in public.

OK, this is getting interesting. Here are the issues noticed, and their resolution:

• gschem wants /etc/ld.so.conf to have a link to /usr/local/lib in it. I am suprised that it is not in RH9, but I'll take your word for it. Yes, I know that RH puts all it's stuff in /usr/lib & most GNU goes by default into /usr/local/lib. They each adhere to a different standard -- there are so many to choose from!

We will look at checking & setting LD_LIBRARY_PATH to include /usr/local/lib when the setup program runs.

• pkg-config. Pkg-config is a configuration utility which reports back info about what compile and load flags should be set when building a package. It is not new, nor specific to any distribution. It's used by configure and make when doing a build. I think it was introduced by the gtk folks themselves. Here's an example run, for a totally random package, openssl:

[sdb@localhost /etc]$ pkg-config openssl --cflags

-I/usr/kerberos/include

It returns the compiler flag -I/usr/kerberos/include, which tells gcc where to find my kerberos/include stuff.

Pkg-config should live on your system too. It calls the gtk2 stuff "gtk+-2.0", and returns the following:

[sdb@localhost /etc]$ pkg-config gtk+-2.0 --cflags

-I/usr//include/gtk-2.0 -I/usr//lib/gtk-2.0/include

-I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0

-I/usr/include/freetype2 -I/usr//include/glib-2.0

-I/usr//lib/glib-2.0/include

Try that out on your system too. You should get a similar result.

Anyway, I think you and Ales are having a nomenclature disagreement. The RPM calls it gtk2, but pkg-config (which is used in configuring and making gEDA) calls it gtk+-2.0.

• Symbols. The installer *did* run to it's end once you left it alone. We agree that there was a dependency issue causing each gEDA/gaf program to remake the symbols as it built each program in sequence. Next time, just relax and let it build.

How long did you let it spin before you pulled the plug, anyway? A typical install session with the CD can run 1 -- 2 hours, depending upon the speed of the machine.

• Installing into /usr/local/bin. Actually, for the installer, I recommend installing your sources into /usr/local/src/geda-sources, (maybe geda-sources-20041228, or whatever version you use) and installing your executables into /usr/local/geda. Then put /usr/local/geda into your $PATH. That way you can nuke it if you ever need to.

:> Interestingly enough, 20041228 has been out for ~18 days and :> I haven't heard of anybody else having build problems (using gtk+ :> 2.2.x/2.4.x; trying to compile with gtk+ 2.6.x is another matter :> because of a function name clash in my code, already fixed in CVS :-).

: 18 days isn't all that long. Have you heard of any *new* users that : have successfully built the system? That would be a more interesting : bit of information.

We have tested this new installer on several machines with several people, but they all knew what they were doing (gEDA-wise, that is). A total newbie install is the experiment we are running on you.

Stuart

Hi Ales and Stuart,

I have finally spent the time to track down all of the problems I was having installing the gEDA suite, and I now think I have a successful build from using the CDROM.

The two things that messed up my build were:

1) I installed pkg-config using the package included with gEDA, only I think I built it as user, and installed it as root. This made the search paths all be based in my home directory, and not in /usr. My redhat installed pkg-config was in /usr/bin, and my gEDA installed pkg-config was in /usr/local/bin. /usr/local/bin comes first in my path, so I was working with the defective version. That's what I get for trying to upgrade pkg-config outside of the rpm/apt-get system.

2) my /etc/ld.so.conf file was stock RedHat, with some additions by other package installations. It did not include /usr/local/lib in its search paths.

Problems/complaints:

1) I don't like to see LD_LIBRARY_PATH and PKG_CONFIG_PATH globally set. They provide a capability for testing new versions of system libraries. I don't believe they were intended to be used system wide. For that you should add the path to the appropriate /etc/xxxx.conf file. It's a shame there isn't one for pkg-config (AFAIK)

2) The schematics in the examples are all composed of main pages with the transistors and diodes being subpages. There is no obvious (to me the new user) way of making the link so the transistors appear on the schematic. Examples are presumably meant for new inexperienced users, and as such should work flawlessly.

3) There are no examples of projects for use with the gEDA project manager.

4) I know it is easier for the developer to run ./configure at the root of each package, but there ought to be a way to only do it once for the whole system when you are using Stuart's installer program.

5) There is really no good reason to rebuild and reinstall the symbols a dozen or more times. It significantly adds to the build time.

Anyway, it seems to be running, and I will begin to explore the construction of a project from start to finish. I'm sure that task will keep me quite busy.

Thanks for the help, and inspite of the problems I had installing, please know that I think you guys have done a magnificent jog thus far.

-Chuck Harris

[. . . snip! . . . ] : Problems/complaints:

: 1) I don't like to see LD_LIBRARY_PATH and PKG_CONFIG_PATH globally set. : They provide a capability for testing new versions of system libraries. : I don't believe they were intended to be used system wide. For that : you should add the path to the appropriate /etc/xxxx.conf file. It's : a shame there isn't one for pkg-config (AFAIK)

: 2) The schematics in the examples are all composed of main pages with : the transistors and diodes being subpages. There is no obvious (to me : the new user) way of making the link so the transistors appear on the : schematic. Examples are presumably meant for new inexperienced users, : and as such should work flawlessly.

: 3) There are no examples of projects for use with the gEDA project manager.

: 4) I know it is easier for the developer to run ./configure at the root of : each package, but there ought to be a way to only do it once for the whole : system when you are using Stuart's installer program.

: 5) There is really no good reason to rebuild and reinstall the symbols a : dozen or more times. It significantly adds to the build time.

: Anyway, it seems to be running, and I will begin to explore the construction : of a project from start to finish. I'm sure that task will keep me quite : busy.

: Thanks for the help, and inspite of the problems I had installing, please : know that I think you guys have done a magnificent jog thus far.

Thanks! We take your bug reports seriously, and will soon do another CD release with at least some fixes to the problems you discovered. I will take a look at the examples today. Keep watching the project page:

Stuart

In sci.electronics.cad Chuck Harris wrote: : Problems/complaints:

: 2) The schematics in the examples are all composed of main pages with : the transistors and diodes being subpages. There is no obvious (to me : the new user) way of making the link so the transistors appear on the : schematic. Examples are presumably meant for new inexperienced users, : and as such should work flawlessly.

Please help me improve the linkage between these schematics. Is your point that you can't open the lower-level schematics from the top level schematic via "Hierarchy -> Down Schematic"? If so, it was a bug in the examples; I have just fixed it.

If you want, try the fix. Edit your gafrc (living in the RF_Amp directory), and add the line (on a new line):

(source-library ".")

Then, open MSA-2643.sch, double click on Q1, and add the following attribute to it:

Attrbute name: source Attribute value: Q1.sch

Do the analogous thing for Q2. Then you should be able to use "Hierarchy -> Down Schematic" in the top menu bar to dive into the models for Q1 & Q2.

Please let us know if this works for you.

Thanks,

Stuart

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?

-Chuck

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

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

The motivation is green (at least the US version is) and there is lots and lots of it to be had.

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Do you know that for a fact? A while ago I was talking to some developers who worked with their company's "European" team on a large software project- in St. Petersburg Russia.

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

snipped-for-privacy@aracnet.com (Phil Tomson) wrote in news: snipped-for-privacy@enews1.newsguy.com:

Meeting in the middle will be very hard for Americans, especially when the middle will be population-weighted billions of Indians and Chinese

200 plus million of us in the USA. Already those high paid Malysians and others in Asia have been squeezed by the even lower cost Chinese. The middle probably represents a per capita income of $5,000.

Once all the technology and industry that are the basis of the USA's strength are transported to Asia, we'll see how our position in the world changes. Once all the technical people are over there, they will be the onese in the drivers seat. And they will not need American CEOS for long. No it won't be pretty.

Since China has its currency tied to the dollar, there has been no self correcting economic feeback loop to stem the trade deficit with them. Otherwise our currency would have fallen against theirs and the price of their products would have gone up. Instead we are in a death spiral with an elephant.

Not that all is rosy for the Chinese or the CEOs sending all the work there. All the Chinese banks are insolvant, there is no financial transparency, corruption is rampant, contracts may not be enforcable, intellectual property is stolen outright, its difficult to take money out of the country, the political situation can change at any moment, a billion peasants are poor and restless and then there is Tiawan.

With those negatives you have to wonder what these CEOs are thinking by placing their balls firmly in the grasp of the Chinese.

Hello Spehro,

It might not always pan out that way. I am just transitioning to a European CAD program so the green flows in the other direction. They didn't outsource it and still had the best pricing.

Regards, Joerg

Yes, I believe that Western Russia (and Western Turkey, for that matter) is European in culture. In this case, there was a deliberate attempt to make it look like the work was done in Germany without actually lying. Kind of like saying "North American" and giving a North Carolina US address, but doing the bulk of the work in Cuba or Honduras.

I imagine that they are indirectly profiting from it.

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

That part of Russia belongs to the old definition of Europe, and most of them wants to join the European Union, because in the European Union it is forbidden to discriminate work.

I think it is more a question what the salary is compared to level and quality of education. Many of the former east-block countries have exellent engineers and they are not so expencive as the western-european engineers.

It is such a pity that most of the politicians who put up the legal framework for globalization never had to face competition on uneven levels

--
Svenn

I read in sci.electronics.design that Svenn Are Bjerkem wrote (in ) about 'Exportability of EDA industry from North America?', on Fri, 4 Feb 2005:

They did , but their levels were the highest!

--
Regards, John Woodgate, OOO - Own Opinions Only. 
The good news is that nothing is compulsory.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk

ATI and Matrox don't pretend to be headquartered anywhere else do they?

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Given the statistics of politician population, that statement smells of racism and sexism.

Hello Spehro,

Sure, as a customer thousands of miles away you may not know for sure. But there is one telltale sign that pops up when you have a tough question. That will often require the original programmer or designer to answer. Accents are really hard to hide. Like with a graphics card manufacturer in Canada. When I got answers such as 'that's aboot right' or I heard 'Bonjour' I somehow knew it's got to be Canada ;-)

Regards, Joerg

No Canada, where ATI and Matrox hail from.