-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interdependencies among different projects #35
Comments
Presently, fobis has not this feature. How foraytool triggers the Il giorno 18:49 dom 15/feb/2015 Jacob Williams notifications@github.com
|
Hi Jacob, I have just read some docs of foraytool (and its source) and I understand that I do not understand you... Let us consider as our prototype scenario the following circumstances:
Is the above scenario plausible? In this case the solution is not simple because: how the sub-target compiled object must track its own sources? Presently, the easiest way is to add an option like With foraytool you specify that the target |
Hey Stefano, I don't quite understand your 3rd bullet point. :) Here's my scenario: The sub-target is a library that contains various modules. So, say I change a subroutine in one of the modules. Then, I go to recompile the main program. The main program is linking to the library (and also using the module within it that was changed). It is clear that what should happen is the main program now needs to be recompiled, since something it is using has changed. This is exactly what FoBiS currently does within a given project. But, now, it would need to somehow do this among multiple projects. It could be as easy as checking if the Or, perhaps you could define different projects or modes within one fobos file and specify that one is dependent on another (like the Also, if you've ever used Visual Studio and Intel Fortran, there is a feature like this to specify that one project depends on another. Also note that if you have multiple projects that depend on each other, this also means the projects themselves have to be compiled in a certain order. Foray also has this, as was mentioned. I only suggest this since it is something that I use, and it is quite handy for projects that are building multiple libraries. However, I recognize that you may not choose to add this feature, since it might get FoBiS away from a KISS philosophy. But, it is something to consider. |
Dear Jacob, this does not broke KISSness (it is an optional feature that "advanced" user can exploit, but it is not mandatory to use), and I am actually working on that, not just "consider" it. What we have to decide is how implement it. My third point is just the main issue. Let me to be more clear. How do you like to track the modifications on libfoo.a? The modifications of libfoo.a will trigger the rebuild of main program, but presently if the libfoo.a is simply linked you cannot be advised of any changes of libfoo.a sources... With foraytool you have 2 targets one depending on the other, not just one target with a linked library... Now, I can view 2 different approaches (and we can try implement both of them, not just one):
Do you agree? Any other suggestions are welcome. See you soon. |
How would you store the hashes? As far as I'm aware FoBiS doesn't create any extra files beyond the intermediate build results, so I'm guessing saving the hashes would mean creating an entirely new metadata file... I can think of a third way: whenever you build something put a copy of everything the linker needs in the bld/ directory, including any external libraries. FoBiS would detect that the library binaries haven't changed and reuse them with its current method of checking files, and an flag can tell FoBiS to compare its own versions of binaries against something elsewhere on the file system. A version of this would be to copy "volatile" libraries (those you expect to change often) only, to save some space. In the extreme KISS limit, just making local versions of the libraries and only linking against those would combine with the existing "clean" command to produce the desired behaviour, with the clean command forcing a complete rebuild and fetching of fresh copies of the libraries. A final remark is that a configuration file can support more complexity than the command line while still being "simple", and I'm fine with restricting the most advanced functionality to the configuration file. |
Hi Tomas, thank you for your contribute.
I am happy that restricting such an advance usage to fobos is fine for you, but my first trial will be to support also the command line. My main concern is about the mechanism:
The first approach is more complex, but potentially more powerful, I suppose. I aspect the response of Jacob and your and then I will try one of them (or a new from you). See you soon. |
Hello Stefano, The current use case is (as I understand it) to ensure FoBiS detects changes to binary dependencies whenever a user rebuilds a project. Interdependent evokes images of something grander, like building a library resulting in automatic rebuilding of everything that depends on it. |
Yes, this is exactly the point...
I think that foraytool has (at least partially) the second behavior, but I do not completely understand what Jacob needs. Anyhow, I am going to implement the simple new binary trigger... |
Hi all, the new version 1.4.0 (both on PyPi and github) has the light "volatile" libraries feature... https://github.com/szaghi/FoBiS/tree/master/examples/cumbersome_dependency_program_volatile_libs https://github.com/szaghi/FoBiS/wiki/Autorebuild-when-external-linked-libraries-change Please, let me know what you think about this. See you soon. |
I'll try to test the "volatile" feature on my projects (probably won't have time until later in the week). Looks like it will be a good feature! Question: does this mean that FoBiS has to figure out the location of the libraries? For example, if you pass a bunch of paths using the The more complex option (defining multiple projects with dependencies) would still be good to have, I think. (Probably there is no way to do it from command line, but it is OK for this to be an "advanced" feature). This has the advantage of actually being simpler to use, since if one project is building a library, and another is using it, FoBiS can handing the linking and paths automatically, without the user having to specify them. |
"Looks like a good feature..." it is your feature :-) Hi Jacob, The volatile attribute is intended to be applied at only the libraries linked with the full path without the linker intrusion (-L and -l switches). The reason is that the libraries linked with their full path are more likely a poor library rather than a system library: track the change of a system library is not a FoBiS.py aim, when this happens just type The interdependency projects (I am really thinking to a fobos files dependency, the notion of projects is currently unknown for FoBiS.py) is in my radar, but I cannot say when it will be ready. However, we can start to discuss some details. I am thinking to something like this:
In this scenario, I thinking to add a special option into the fobos like the following (I am using the default section just as an example, but it can be used into any defined modes) [default]
dependon = ./relative_path_to/fobos_lib:static
compiler = ...
.... Note that I have specified not only the fobos file but also the actual mode (section) that in this case is What do you think about this feature (that is your :-)? @Tobychev What do you think? See you later. P.S. @jacobwilliams I have just realized that you use MS Visual Studio... you are not so poor Fortran man :-) because I do not use such a tool (I cannot live without vim), please feel free to request any useful features of Visual Studio that FoBiS do not have (yet) |
Dear all, in v1.4.3 the volatile has been extended to also library linked via -L -l switches... some notes
For MS windows users I needs help... |
Dear all, in v1.5.0 also the more complex inter-dependency projects feature, see
I hope both of you agree with this implementation, anyhow I will happy to accept any suggestions. See you soon. |
Terrific! Will try and test it next week when I get a chance. I like the implementation of referring to the fobos file of another project. I think that is better for some situations than the way foray does it (where everything is in one monolithic file). Question: can I have multiple projects in the Visual Studio is actually not a bad editor. The Intel Fortran integration does the dependency analysis automatically among multiple projects, so I don't have to worry about it. |
Dear Jacob, in the new version 1.5.1 (besides some bug-fixes) your feature request should be accomplished: now For more details see
Please, let me know your opinions. See you soon. |
I have added a screencast for you |
Very nice! I have another suggestion: In your example, the main fobos file has this:
It would be great if only the |
I think you are a very smart man... nice suggestion: the user likes KISS Have a good weekend
|
Hi Jacob, You must give me more details for your new feature request. When Maybe, we can agree that when Thank you for your help. |
Dear all, I have just uploaded a new version (both github and PyPi), having the requested features, namely automatically add ext_libs = dep1 dep2
dependon = ./dependency_lib_1/fobos_lib:static ./dependency_lib_2/fobos_lib:static I close this issue, but I will reopen it if anyone ask me more. See you soon. |
Terrific! |
Hi Jacob, dependon = lib_foo/foo_fobos:static(indirect) This is just a paranoiac precaution... Anyhow tomorrow I will push the new version with the direct link forcing. |
Hi all, the new version v1.5.3 (upload on both github and PyPi) the Jacob request should be accomplished (with my paranoiac compromise...): now defining
See you soon. |
Say I was using FoBiS to compile libraries which are in turn used by multiple programs (an example can be found here). I believe currently, if I make a change to a module within the library, the main programs are not recompiled (since they are only linking to the
.a
library file that is produced by a previous FoBiS call, and have no knowledge of how they are interdependent). Is there currently any way to tell FoBiS that one project depends on another? (Note: I'm getting this idea from foraytool which has this feature).The text was updated successfully, but these errors were encountered: