Using Rational Quality Architect Real Time with Clear Case ( 8.0.1.19). I have a build issue where updates to a single actor do not become part of the build. Wink in is being used.
In the build sub directory for the Rose RT target, I see a ".o" and ".d" file for the generated code of other actors. For the problem actor I see a ".o" that is old and no ".d". A new .o is not compiled even if the problem actor is checked out and modified. The Rose generated c++ for the actor does not get recompiled even though it is newer than the corresponding object file.
If I use the -V option for clearmake which disables wink in. The build completes properly. Ideally I would like to keep the time savings of winkin rather than turning it off for one file..
Related
After changing single line of code and performing Xcode 10.1 incremental build in large project, Xcode spends most of build time in "Compile swift source files" phase after completing all listed tasks (compile changed files and merge swiftmodule are both completed)
screenshot showing tasks list: https://imgur.com/a/JoVI0zB
While compilation and merging swift module takes less than second, whole phase can take up to 2min in my project (300k LOC).
What does Xcode do in this time? Is there any way to speed up this process?
Similar project written in Obj-C takes just few seconds to launch after changing 1 line of code.
I have this same issue and after a lot of investigation I have determined that whatever it is doing, it is based on the number of swift source files you have.
The Root Cause
In the 2018 wwdc talk about the Xcode build system the presenter says (searchable in the transcript of the video):
What this means is that unlike Clang, when compiling one Swift file, the compiler will parse all the other Swift files in the target.
So even if/though the incremental build only needs to recompile a single file, it still parses every other swift file.
Our project has over 2000 swift source files and we are seeing incremental build times of 3+ minutes for recompiling a single independent file.
Testing to prove the root cause
Because hearing it in a WWDC talk is not enough, I did the following to test it myself:
Created a new project
Tested incremental build times for nearly empty project, changing a single file
Incremental build completes nearly instantaneously (< 1-2 seconds)
Used a script to generate 2,000 swift files, each containing a simple struct with a unique name, 2 variables, and a simple function. There are no dependencies between any of the files.
Add the directory containing the 2,000 new swift files to the project and complete a full build.
Test incremental build times again for a single file
Incremental build time took more than 1 minute
In my testing, the complexity of the contents of the additional swift files does not seem to be significant, only the number of files.
The Solution - Modularization/Frameworks
Separate your app in to smaller frameworks to reduce the number of swift source files in each target.
This is a decent guide showing steps on how to go about this if you don't already know how.
In my test case above, I created a new framework and moved the 2,000 swift files into the framework and then tested incremental build times in the original project (importing the framework) and the build times were back to < 1-2 seconds. Of course doing an incremental build inside of the framework would still be slow, but ideally you would split the project into many and smaller frameworks so that each will have faster incremental build times.
Not the Solution - Merging Files
If the problem is the number of files, why not merge a bunch of files to reduce the number? Because it will likely result in slower incremental builds.
According to 2018 WWDC's Building Faster in Xcode:
Swift's dependency model is based around files
This relates to our current problem because it means that any change to a file (except for changes to function body contents only) will cause recompilation for any file that depends on ANYTHING in the changed file.
If you merge many types into a single file, it will result in more code getting recompiled on incremental builds if any of the changes touch the large file or any of its dependencies. It will also increase the number dependents the large file has, making it so all of them get recompiled if ANY of the types in the large file are modified.
I've been given the task of researching whether one can use Powershell to automate the managing of References in VB6 application and then compile it's projects afterwards.
There are 3 projects. I requirement is to remove a specific reference in each project. Then, compile projects from bottom up (server > client > interface) and add reference back in along the way. (remove references, compile server.dll >add client reference to server.dll, compile client.dll > add interface reference to client.dll, compile interface.exe)
I'm thinking no, but I was still given the task of finding out for sure. Of course, where does one go to find this out? Why here of course, StackOverflow.
References are stored in the project .VBP files which are just text files. A given reference takes up exactly one line of the file.
For example, here is a reference to DAO database components:
Reference=*\G{00025E01-0000-0000-C000-000000000046}#5.0#0#C:\WINDOWS\SysWow64\dao360.dll#Microsoft DAO 3.6 Object Library
The most important info is everything to the left of the path which contains the GUID (i.e., the unique identifier of the library, more or less). The filespec and description text are unimportant as VB6 will update that to whatever it finds in the registry for the referenced DLL.
An alternate form of reference is for GUI controls, such as:
Object={BDC217C8-ED16-11CD-956C-0000C04E4C0A}#1.1#0; tabctl32.ocx
which for whatever reason never seem to have a path anyway. Most likely you will not need to modify this type of reference, because it would almost certainly break forms in the project which rely on them.
So in your Powershell script, the key task would be to either add or remove the individual reference lines mentioned in the question. Unless you are using no form of binary compatibility, the GUID will remain stable. Therefore, you could essentially hardcode the strings you need to add/remove.
Aside from all that, its worth thinking through why you need to take this approach at all. Normally to build a VB6 solution it is totally unnecessary to add/remove references along the way. Also depending on your choice of deployment techniques, you are probably using either project or binary compatibility which tends to keep the references stable.
Lastly, I'll mention that there are existing tools such as Kinook's Visual Build Pro which already know how to build groups of VB6 projects and if using a 3rd party tool like that is an option, could save you a lot of work.
I use Delphi 7 and I encountered a very annoying thing. One of my projects has gone quite large and a form I used in one of the units became obsolete. I decided to get rid of it. It seems I can't. The IDE always asks for .dfm file, no matter what i tried (and I think i was very thorough).
Here's what I did:
First, I used the IDE's Remove from Project to remove the whole thing from the project. Then I commented out all sections that used anything in that unit and compiled, bulit and ran the project. It went without any errors or warnings. I saved all files and closed the Delphi IDE, started up a Notepad and removed the form's declaration from the unit, then deleted every associated file, except the .pas (with this, it became like any other regular unit).
Then I searched every file in the project's folder with Total Commander to see if any of them contained the name of the removed unit. None did.
I started Delphi and loaded the project.
With this I felt satisfied and added the unit's name to the uses list and pressed Compile.
IT STILL LOOKS FOR THE DAMNED DFM!!
If someone knows, please explain this to me. What did I miss?
If the compiler is looking for the .dfm file it will be because the compiler is including a unit that contains this:
{$R *.dfm}
That is what tells the compiler to link the .dfm file with the same name as the unit.
It seems likely that you still refer to the unit somewhere in your project. The compiler must be finding either a .pas file or a compiled .dcu file for your unit. Search for all files named <UnitName>.pas and <UnitName>.dcu. Remove these files. Then you will encounter compiler errors whenever you have code that attempts to use those units. Deal with those by removing the unit from the uses clause that names it. Then you should be done.
Today I cleared my .ivy cache and cleaned my project output targets. Since then I have been getting really strange behaviour when running tests with SBT or editing in the Scala IDE.
Given the following:
package com.abc.rest
import com.abc.utility.IdTLabel
I will get the following error:
object utility is not a member of package com.abc.rest.com.abc
Notice that com.abc is repeated twice, so it appears that the compiler uses the context of the current package when doing the import (maybe it's supposed to do this, but I never noticed it before).
Also, if I try to access classes in package com.abc from anywhere inside com.abc.rest (even using the full path) the compiler will complain that the type can not be found.
It appears that the errors only occur when I try to include files from parent packages. What I do find strange is that my code used to work. It only started happening after I cleaned up my project and my ivy cache, so maybe a later version of the compiler is more strict than the previous one.
I would love some ideas on what I can be doing wrong, or how I can go about troubleshooting this.
Update:
By first importing the parent classes and then defining the current package, the problem goes away:
import com.abc.utility.IdTLabel
import com.abs._
package com.abc.rest {
// Define classes belonging to com.abc.rest here
}
So this works, but I would still love to know why on earth the other way around worked, and then stopped working, and how on earth I can fix it. I had a good look, and could find no packages, objects or traits by the name of com anywhere inside the parent package.
Update relating to Worksheets:
Scala worksheets belonging to the same package share the same scope, which sounds obvious, but wasn't. Worksheets are not sand-boxed - they can see the project, and the project can see them. So all the 'test' object, traits, and classes you create inside the worksheet files, also becomes visible in the rest of the project.
I have so many worksheets that I did not even try to see where the problem came in. I simply moved them all to their own package, and like magic, the problem went away.
So, lesson learned for the day: If you create stuff inside worksheets, it's visible from outside the worksheet.
Anyway, this new found knowledge will come in handy, meaning anything 'interesting' can be build, monitored and tweaked inside the worksheet, while the rest of the project can actually use it. Quite cool actually.
It's still interesting to think how a sbt clean and cleaned up ivy cache managed to highlight the problem that was hidden before, but hey, that's another story....
(At the request of JacobusR, I'm making a proper answer out of my earlier comments).
This can happen if you have defined some class/trait/object inside package com.abc.rest.com. As soon as package com.abc.rest.com exists, and given that you are in package com.abc.rest, com would designate com.abc.rest.com as opposed to _root_.com. Fastest (but non-conclusive) way to check, without even scanning the source files, is to look for any .class files in the "com/abc/rest/com" sub-folder.
In particular you would get this behaviour if any of your files has duplicate package definitions (as in package com.abc.rest; package com.abc.rest; ...). If you have this duplicate package clause somewhere in the same file where you get the error, you wouldn't even see anything fishy with the .class files, as the failure at compiling the file would prevent the generation of .class files for any class definition inside the file.
The final bit of useful information is that as you found out the scala Worksheets are not sandboxed, and what you define in the worksheets affects your project's code (rather than only having the project's code affecting the worksheet). So a duplicate package clause in a worksheet could very well cause the error you got.
If package names conflict, there might be a custom error message for that. See if specifying the full path resolves the issue by starting from __root__. Ex. import __root__.com.foo.bar._
i'm looking for a way to import an existing xpo-export via command-line into ax2009 aot and afterwards compile just this imported xpo. google tells me how to compile the whole aot by commandline, which takes quite long.
so is there a way to import an xpo ( shared project ) and compile just these objects?
what possibilities are available, if the objects which should be imported are version-controlled by ax and are checked-in?
hoping for an easy way to automate optionally check-out, import, avoid overwrite?-questions, compile and run ;)
thanks in advance!
You can make you own startup command:
Make a new class and extend SysStartupCmd
Change the construct method of SysStartupCmd to call you class.
Do whatever you need, this includes parsing the parm variable.
Also you will have to deal with version control by calling checkin/checkout in your code, handling compile errors etc.
There are no easy way, this is complicated stuff.
Over the last two years I have introduced and refined a command line process for deploying XPOs to AX 4.0 with great success. The class SysAutoRun is key as mentioned above. The following is a brief explanation of the resulting process:
Developers export AX objects from the AOT to a corresponding folder(layer) i.e. CUS, VAR, etc... for the most part the file name is the default file name set by AX.
Developers commit using SVN in this scenario. This would have to be evaluted to meet your needs.
Console application for the build process reads all file names from each directory(layer) and creates corresponding AX project definition files.
Console application reads all file names from each directory (again) and creates an import definition file for each corresponding layer(folder). The project definition created above is also instructed to be imported after all other objects are loaded and finally compiled. The import definition contains some specialized elements that are recognized by the SysAutoRun.execCommand(XmlNode _command) method.
A call is made to ax32.exe "config.axc" -StartupCmd=AUTORUN_ImportDefinitionMentionedAbove.xml -lazyclassloading -lazytableloading -nocompileonimport -internal=noModalBoxes
AX parses this import definition file invoking customizations as instructed. Logging is added to the process for outputting compilation results to an XML log file. Finally step 3's project definition file is compiled.
Console application validates the outputted XML log and handles appropriately.
Step 5-7 is repeated for each (folder)layer.
I understand this is very vague. The intent of this post is to get feedback on interest before I invest more time on describing the process. The import definition file is probably of most interest as it is responsible for loading the objects in the right order, synchronizing the ORM, compiling, repeating, etc...
Thanks M#