 So I started working again on the Project Manager back when I had everything in Fossil Repositories. If you ever check those out you may have noticed there was some attempts at it that I abandoned. Picking that back up. Now this is something I had implemented like two three years ago but like so much of the other stuff it's really needs to be rewritten well before a public release and so that's that's what I've been doing. The original implementation was bad, quite bad, but nonetheless the approach it's taking is basically the same. Now I do want to take a bit of time to explain exactly how this is going to work because it's different than you might expect. It's definitely considerably different from GPRs which would be important because why implement something that already exists. GPRs do what? GPRs do well. Well I know that's ridiculous thing to say but that's they're really good for building like firmware and stuff for embedded systems. They're not good for what I'm trying to do. So a little tiny little bit of background information about Ida just just to get anybody who's stumbling across is not familiar with Ida. Familiar. Up to speed. Ida essentially has three different types of files that can exist for it. You have the program which is just either a one of two different types of blocks basically. You have a procedure or a function and it's either one of these. Not both. That's important to understand. But then you also have, if I could spell, a package. Actually that looks really bad. Let's... there we go. Much, much better. The double E not so much but apparently I write like I type. It's terrible. With a package you must have a specification. So we can do that. But then there's an optional body and how would I represent this exactly? I guess that works. So then just to reiterate a program you either have a procedure or a function but regardless it's a program and for a package you have to have a specification and you may have a body depending on what is in the specification. It's this that's interesting. This is straightforward. Building that is easy. It doesn't even need a project manager. Building this is where it gets a little bit interesting. So one thing that is important I would say should be required. Idecor says sort of optional. The naming rules are very sophisticated for GPRs. So you can get away with... you can get away with unique names for each of these but I would strongly recommend against it. And like for what I'm doing it's going to be required that they have the same name. So you would have something like example.ADS and then if it actually implemented a body you would also have example.ADB for the spec and the body respectively. Inside of there you would also see this name should be present as the actual package name. Now GPRs do enforce that kind of behavior. In fact basically NAT in general enforces that kind of behavior. Again with some of the naming progma stuff you can get away without that though. The way projects are normally built in ADDA at least using GPRs. Anything else even remotely associated with this example package would also be built together. So if we have another package of say foo.ADS and then another one of say bar.ADS but there's no associated body with this using the normal GPR method the GPR projects. All three of these would be built into the library which might just be called something like example.ADS. So for you know shared libraries under Linux it'd be a DLL under Windows. I think Mac I know they're MacOs but I'm not sure what the extension if any is for that. So if you're only a Mac developer I'm sorry I don't know what it would be but it's whatever the library is you know it's all built into one large shared object. And this this can be appropriate behavior in many instances but one of the nice things about the way shared objects work is they're shared they they link together hence the name dynamic link library with the windows ones but they're not the only type that implements dynamic linking. What I've been able to do manually and would like to have better automated is instead of this each into their own shared object and then any links between them can be established. So let's say example depends on bar and so then anytime bar the the bar package or bar library was loaded only that would be loaded but if example.so was loaded then it would just because of the way the linker works also have to load bar.so and food.so. This might seem like a little bit of an over complication but what it allows us to do is replacing the specific libraries and because each package is built into a specific library you can replace essentially at the it can like conceptually at the source level a replacement of the package is also just a replacement of the library or vice versa this is important because when you want to do optimization for say specific instruction sets say the AMD64 architecture the you know extension to the 80686 it you want to do something like array math linear algebra you can of course iterate through step by step and calculate each number individually and go through the entire amount like that it's fine it gets the job done it's obviously not the most efficient way of doing it but it definitely gets the job done now in a system that doesn't support this fine grained creation of libraries what you would often do with some type of check for whether those features are supported and have them in the in the library so that if they are supported it happens but if they are not the default the default that will work on anything in this case the iteration through the arrays happens that's fine but you do have in order to calculate anything additional branches that are occurring because that's that's what the if else stuff is is fundamentally a branch this can be rather problematic if a branch misprediction occurs now you would hope that a good compiler can recognize these types of things uh i've personally seen instances where it doesn't although admittedly most of the time it's good about getting it but this also does lead to some code bloat because you know if you think about it all the all the uh checks and the stuff that will be happen if that check comes true have to be put in there now of course a slightly better approach to it is conditional compilation where you build it for the target architecture and only the relevant stuff goes in there that's certainly uh much much better uh approach to this and notwithstanding a few other issues would totally accomplish what i want to do here it's the other issues that is why conditional compilation is not enough because uh there is a nap preprocessor that i could use for conditional compilation where it gets a little bit more complicated is when you have legacy code is a great example if these things are built with a good degree of modularity replacing one of the libraries say for array math of a pre-built executable to where that library now does sim instructions that executable will automatically start doing the sim instructions this is one of the biggest benefits to shared libraries but the there's two issues that are commonly faced with that one is that the interfaces break easily in some languages that c++ is notorious for having the interface break uh regularly now that there are ways to help not happen but i did happens to do a really good job of keeping very consistent interfaces and in large part that's due to having the separate specification and bodies it's not the only language to do so but it definitely helped um also worth noting the separate specification and bodies is not enough uh c++ has its separate headers and bodies and the the interface still breaks regularly with c++ so it's not enough to have that there has to be a number of under the under the hood things going on to help ensure that the interface remains consistent but um the presence of ali files and other things help immensely with that as well for those not aware ali files are essentially add a library files they're a table of sorts for what's the library has at the source level and where it is in the library more or less it's a it's more complicated than that but it's essentially a look-up table for the library to help provide that consistent interface so one of the other reasons to have the high degree of modularity though is with licensing there is definitely not even close to an agreement when it comes to licensing and at least with me i'm definitely very comfortable releasing my code under very liberal open source licenses i tend to avoid the gpl like the plague that being said i also tend to avoid a few other open source licenses like the plague but most of my stuff is available under one of the bsd 2 3 or 4 clause licenses exactly which depends on the project though but that doesn't mean that all of what i write is some of what i write is definitely closed source and there are businesses that would like to do the same in that kind of instance if everything's well modularized what we would be able to do is say like my mathematics packages uh all of the stuff that i've developed hasn't been rewritten yet but even now even currently you can see that there's quite a bit in there if a business wanted to come along and provide or even just another developer an entity just somebody something wanted to provide one of those packages with the same specification but a different body and have the body closed sourced they would be able to do a drop in replacement of just that package and not have to redistribute the entire thing so really with existing package managers there's nothing stopping you from doing this it's just an insane amount of work uh using gprs you would have to create a gpr for every single package so that it's built as its own unique library that is a lot of work um furthermore because the gprs have project dependencies you have to specify each project library and it just becomes this huge maintenance nightmare but i've noticed something when it comes to ida source files other languages too but they're talking specifically about managing ida projects hmm i don't want to do that that works there we go forget my own program sometimes generally speaking the layout of an ida project looks or an ida package looks something like this fair enough simple enough but then you have the dependencies up here now this should not be surprising to basically anyone because almost any programming language has them up here instead of having these projects figure out what they depend on we can use the actual with declarations to gather up all of these and create a dependencies list not of the projects it depends on but of the packages it depends on now i would like to be able to build the entire ida standard library using this package manager but even in the meantime as kinks are worked out and everything it would be possible to since the ida standard library exists as a built library on any distribution anyways just sort of silently discard any of the standard library packages but still include in the non-standard packages that are declared as long as these packages are in a visible location such as the ida include path and the ida objects path it would be able to appropriately build with them and link to them then because of this you can automatically inject the appropriate flags into the compiler argument yeah into the compiler arguments on the command line so that all of this just sort of happens now i sort of got big on this before it became cool because you know fucking nerdy hipster please kill me but in recent years it's sort of become trendy to treat the folder as the project i get this from way back having grown up on b.o.s where because of tagging and other stuff the file system was actually like really powerful from an end user standpoint but i got used to viewing folders as more than just folders and so if you think about it it really makes a lot of sense to treat the folder as the project so you can have the project manager just go okay let's find all of the ida sources in this folder they're all the project files done if you have a more complicated setup than that this project management tool is probably not going to be what you need anyways and you're probably going to want to be using gprs or make files see what i've designed and then now re-implementing in a better way because oh my god it was so bad um is designed around being really easy to build libraries which is something overwhelmingly project managers sort of skip sort of don't care about it's almost like an afterthought if you ever really think about it and look into like the documentation of different project managers whether it's gpr or the ms build or any of these things it's overwhelmingly about building executables building programs which is fine i just think we can do a little bit better especially when so much of this stuff is marked up in the source code already now i do i have been implementing some of this i've just started today so not a whole lot exist yet um i am developing this in c sharp mostly just because it's going to be considerably easier for me to get this up and running in c sharp um i'd be willing to do a rewrite into aida in time but quite frankly it's not a high priority having the working project manager is a considerably higher priority than what language it's written in um one of the other things that it being in c sharp enables me to do very easily is have an appropriate power show module for it the standard program with like very you know posix syntax would be very easy to generate anyways it's the power shell syntax that i'm a little bit more worried about because i would like would very much like to have that be properly implemented so hopefully in the next few days you start to see a little bit of of showcases over what this project manager can do right now it's not a whole lot but i've almost got the dependency lookups working correctly so it's coming see you