I have a custom QSys component, that instantiates a couple of Altera IP. The Altera IP is also in the form of .qsys files. Is it possible to have Qsys recurse through my custom component and generate the instantiated IP for me? Currently I have to open each IP separately and generate it, only then does the component synthesize properly?
Qsys distinguishes between components (defined by a .tcl file), and subsystems (defined by a .qsys file). It looks like you want to use subsystems.
The procedure for adding either of them is basically the same though. Add the path where you store the components or subsystems to the IP search path in Qsys preferences. After you refresh the system those components and/or subsystems should appear in the component list, and you can instantiate them like with the built-in components. Subsystems should show up in the Project -> System group in the component tree. When you generate the system, the subsystems will be generated as well.
While this is how it's supposed to work, there are various bugs in different Quartus versions that can give you some problems. The easiest and safest way is to keep all the .qsys files (both the top system and the subsystems) in the directory of your Quartus project, and launch Qsys from Quartus when your project is already open.
Related
With respect to external libraries and File Exchange packages, I'm trying to make my MATLAB code more compatible with the multiple systems I run it on.
For example, let's say I want to run my code on two differently setup Windows systems. The function depends on an external library not located within the current work directory, but rather as shown below:
System 1
addpath('C:/SomeFolders/Git/3rdParty/Library')
System 2
addpath('B:/Git/3rdParty/Library')
The current working folder for both would be '.../Git/ProjectFolder'
Is there a way to have MATLAB navigate ("go-up/down") the folder hierarchy levels and search for the desired library?
Cheers,
We have a project here written in VB6 (yes, I know...) which consumes some ActiveX objects also written in VB6 (OCX files).
Recently we started using a build server for this project and, with the help of the MSBuild Extension Pack we devised a build process which compiles the libraries, controls and executable all in the correct order, registers them as appropriate and then unregisters everything to leave a clean machine for the next run.
The problem is that each compilation run leaves entries in the registry for the extended type library/object cache files which the VB6 compiler appears to require, and these entries are not removed when the controls are unregistered.
i.e. for every registered component which has a CLSID entry pointing to the OCX, there exists, after we compile the project with VB6, a newly generated CLSID for the OCA.
Because we unregister the OCX controls after each build and the OCA CLSIDs are generated afresh each time, the number of OCA entries continues to grow.
Does anyone know what causes these entries, whether we can remove them through some kind of unregistration process or whether we can prevent them being created in the first place?
A few notes :
The build machine is Windows 7
Binary compatibility is enabled, so the CLSIDs of the OCX controls aren't changing.
Reg-Free COM isn't currently an option
We cannot simply register the controls and leave them as we want to run more than one build of this project.
The key is to stop trying to treat DLLs (including OCXs) like statically linked libraries. Your build process is inappropriate.
While VB6 supported a crude "project group" capability, this was only meant for small scale unstructured development efforts like those used by under-the-radar business unit coders.
Instead strive to keep application-centric logic within your EXE projects. Factor out longer-term reusable logic into DLL and OCX projects that you treat as separate, unique internal products. Maintain these (including source control) compeletely separately from consuming applications.
Normally these should be far more stable than application code where changes are driven more frequently by the business logic they contain.
Even when some of these must contain business logic, you still want to treat them as separate software entities. Try to keep them distinct from libraries that have more stability.
This requires more discipline than monolithic "tower of Bable" development but there are many rewards. Build time is quicker for one thing. And as a bonus almost all of these source control related issues disappear for the applications which have a much higher rate of tinkering and fiddling.
I'm maintaining a VB6 application with many COM components (DLLs and OCXs). In order to streamline development and deployment I'd like to use reg-free com. The problem with development is that the application runs within the VB6.EXE instance. How can I trick VB6 to use my (unregistered) components? It is very important for me to not have to go through registering/unregistering components when switching between branches. Generating a .manifest file for VB6 is not out of the question but is there some other, more optimal way, to specify a .manifest file when launching VB6.EXE?
Note: The Activation Context API doesn't seem to help, even if used from within the development environment.
Solutions I've thought:
A utility application that activates a context from a manifest and launches VB6 as a child process (doesn't work; processes don't inherit activation context)
Injecting context activation into the VB6 process at startup (too complicated; must hack the executable to do this)
Hosting VB6 in my own process after activating the right context (can't even find out if this is possible)
Using a VB6 Add-In or other utility that runs within VB6 to activate a context (tried that but it doesn't seem to work)
Update Jan. 16
As suggested by wqw, I did some testing with a VB.exe.manifest. The VB6.exe.manifest worked, with some caveats:
The SxS dll specified in the manifest would not appear in the references window on projects that didn't actually reference the component
On projects that did reference the component it would be shown to reside in the directory according to the following order:
The pathname recorded in the project file (if the file was still present)
A pathname as if it resided in the same folder as the project (vbp)
If the file was not in any of these folders, the project would not compile (just running the code causes an internal compile in VB6) with the message "Can't find project or library".
Obviously, VB6 actualy scans the registry to find COM components and verifies, during compilation, that they exist where they say they exist. I'm not sure what that might mean if I actually want to use VB6.exe.manifest to redirect COM component instantiation. Perhaps having dummy component files at some predefined location might trick VB6 into believing that everything is as it should be, although an entirely different set of components got loaded for use.
Further update:
I did a test on that last assumption and it proved to be false. The component has to actually be there in order for the project to compile. It must even properly load (no dummy, zero-length files accepted!). Now I'm not even sure if the manifest works. That's a more time-consuming test (requires a component with two versions that produce different results, one with the project, and one for the manifest).
Our approach to this problem was to write a build assist program that registered and unregistered components, run the VB6 compiler, and would even rewrite project files with updated GUIDs when interfaces changed. You would hand it a VBG project group and it would do the rest.
I suppose we could also have added a mode that unregistered components when you switched branches.
Are you following the practice of using "compatibility" binaries? You shouldn't use the binary at your build location for compatibility references - you should commit a separate copy to version control and configure your project to consider that the "compatible" version - only change this file when you break interfaces.
We have an application consisting of multiple components: main app (installed in program files) and multiple datasets (located in AppData). In the future there will be available (also) individual updates for one of components. What I want is to create one installer for all components, but create multiple uninstallers for components accessible from Programs and Functions. I've looked at Inno Setup, but I think it doesn't support this. Also tried NSIS, but it looks much difficult to use.
Wouldn't it be just as well (or better?) to make it all one install/uninstall program. And it works by noticing which features are present? If none then your screen consists of check boxes with what you want and don't want, then upon running it again later you would uncheck what you want to remove, etc.
Two of our programs use the same COM server (also made by us) with the same class ids. Each program when installing copies the COM server files into its folder and regsvr32s the COM server.
The problem is how to install the COM server so that the user can install either one or both of our programs into different folders in any order and likely of different versions. Clearly it's impossible without changing the class ids and that's lots of hassle with configurations. Ideally we would like to use manifests for that and go without regsvr32.
The problem is every time I read about reg-free COM (for example, here) there's the version attribute in the assemblyIdentity. The version number should change every nightly build and I totally don't like the idea of (automatically) adjusting it. I understand why specifying dependency on a specific version is good, but it's completely useless in our scenarion.
Is there a way to write manifests for both the COM server and the consumer so that they don't specify versions and just work with whatever version of the file happens to be in the folder? Also is there a way to restrict the search to the same folder as the consumer?
Windows searches for manifests only in the global location followed by the application directory. If you don't install anything globally, search is effectively restricted to the same folder.
If you're always shipping the COM server in the same folder as the COM client, they are effectively one "software unit". version considerations are interface contracts between different software units, so in your scenario it doesn't matter. You can either omit the version attribute from the identity or set it to something fixed like "1.0.0.0", knowing that at that point, it's up to the way you distribute the software to ensure the proper versioning story, and not the side-by-side system.