Is there a way to "link" specific content from one repository to another?

Asked

Viewed 163 times

1

I have a program that needs some DDLs, those DDLs are available in another Git, also on Github. Therefore, it would be possible for my library link such a file to such a repository?

To be more specific, there is a DDL (github.com/c-Smile/.../64/sciter.dll) and it is used in my program. I wanted to include it here, along with the main.go, instead of having to do it manually.

It would be possible to create a sciter.dll aimed at that Github? A sciter.dll which would be fictitious, where when using the go get -x or git clone would go to the github.com/c-smile to obtain this content.

That’s possible, how would you do that?

git github

2 answers

2


I think there’s a way to do what you’re thinking, which is to link a module from another project to your.

  1. Navigate to finish to your project directory and type: git submodule add https://github.com/<user>/nomeModulo nomeModulo
  2. If your git version is old, now type this command: git submodule update --init --recursive

Okay, you imported the sub-module into your project!

0

Good practice for this problem of yours is to use a; package manager or package management. Package managers are best known to general users on systems GNU/Linux, by enabling the installation of programs or applications from the console. The best known are: APT (Advanced Packaging Tool), RPM (RPM Package Manager), among others... In Windows we have the Chocolatey.

Already in software development, when we work with componentization, with the aim of distributing pieces of the application; there must be a concern of how to distribute this component. Since duplicating code is not an alternative, and not centralizing the distribution of the component, it can lead to disuse in large companies. This is what package managers are for!

Used for both back-end and front-end components, we have specific options for each language or platform. Following list of several acquaintances:

If your packages can be public, there must be a repository for Go that you can use. Hence your build process should have access to that repository to use the published package. If it has to be private, you must have this management in your infrastructure.

You can also search for universai package managers, who accept various feeds, from various languages. Take a look at Azure Devops Packages.

  • This seems to me to increase complexity more than to reduce it. A dll (so, dylib) is only used for the graphical interface. When you do the clone (or uses go get) may execute the go generator that will pass the dll to any variable, since compiling statically does not work. Thus, at each use this dll is uncompressed by the application and consumed. The reason you import it to Github is to make it easy to build, as you won’t have to copy the dlls manually if you build. For general use, the result of the go build, the exe, is enough. Or, I got your post wrong.

  • I didn’t understand pieces of your text, so I didn’t have the full understanding of your process. A dll in question, is it from a public project? External to your/or your business? What do you mean by "unzip the dll", since it is not possible to unzip a binary. If go build is sufficient, at what point do you use this other compilation and for what?

  • A dll is publish, not produced by me. O go build is only necessary if someone wants to change my code, which is open. I believe it is ideal to facilitate editing. ddl is built into my program. When you use go generate adding a code creates the sciter_windows.go he will have the var DLL = {0x00.binario..}. When you use the program, the dll will be unpacked (like os.Write(DLL)) and then used. For the end user, who already downloads the exe, there is no need to have the dll because it already has. The problem is who wants to compile that ends up having to download manually.

  • In short, the dll is needed because it is part of the code, literally. So for someone to compile (to create the one var DLL = {conteudo do dll}) must have the dlls. Currently the person must go to the Sciter site and download it, then include it in the folder and then use the go generate, Seems like a waste of time to me. If I include direct dlls on my Github I will have to keep updating, but this still seems to be the best way out, but there is the issue of licenses.

  • It’s your decision... I gave the best practice, which is the one used by the market, and why it’s not a waste of time.

Browser other questions tagged git github

You are not signed in. Login or sign up in order to post.