Copy external libraries into build folder last

Glider (IDE)
#1

Hi,

When setting build configurations in Glider, the external libraries are copied first to the build folder then the main library/project is copied. Hence, for example, if there is a ‘vars.lua’ file in the external library and a ‘vars.lua’ in the main library/project the file from the external library is copied first into the build folder and then it will be overwritten by the file with same name from the main library/project. 

I would like to control the order of copying files into the build folder. In my case, reverse the above order and have the external libraries copied last into the build order and, therefore, files in the external folder would overwrite conflicting files. How can i achieve that?

I tried tinkering with ‘GliderProperties.proj’ but that didn’t work (or i didn’t know how to do it). Is there a way?

Thanks.

UPDATE:  I know there is a ‘Include Before’ and ‘Include After’ options when adding libraries to the build configuration. But they seem to only control the order of copying the individual external libraries. In my case, i want the whole external library/libraries to be copied AFTER the main library/project.

#2

Hello Mazrabul,

We initially designed it this way so that you cannot accidentally overwrite the main.lua file and cause some serious confusion. Would it be possible to just remove the var.lua and put it into external libraries? You can make multiple configurations, each with its own external library and each with its own var.lua.

Maybe there is another use case we have not thought about? Please explain if you dont mind. 

Regards,

M.Y. Developers

#3

Sure.

In this particular scenario I have 4 very similar apps. They differ from each other in the following ways:

  • Default.png s are different

  • Icons are different

  • audio files are different

  • the contents of some lua files are different

So, i thought i would set up a base app and set it as main project. Then create 4 build configurations one for each variation of the app. That way, when building any app variation, the files for that particular variation would overwrite the similar general files in the base app.

I hope i was able to explain this properly.

Thanks 

#4

Hello Mazrabul,

Thank you for explaining your use case, it really helps. I think you should put these general files into its own library so that you will have full control over the order you include it in the build. We are a bit nervous about overwriting any main project files because it has caused some unexpected and surprising results in the beta tests. Would that be an ok workaround? 

Regards,

M.Y. Developers

#5

Hello Mazrabul,

We initially designed it this way so that you cannot accidentally overwrite the main.lua file and cause some serious confusion. Would it be possible to just remove the var.lua and put it into external libraries? You can make multiple configurations, each with its own external library and each with its own var.lua.

Maybe there is another use case we have not thought about? Please explain if you dont mind. 

Regards,

M.Y. Developers

#6

Sure.

In this particular scenario I have 4 very similar apps. They differ from each other in the following ways:

  • Default.png s are different

  • Icons are different

  • audio files are different

  • the contents of some lua files are different

So, i thought i would set up a base app and set it as main project. Then create 4 build configurations one for each variation of the app. That way, when building any app variation, the files for that particular variation would overwrite the similar general files in the base app.

I hope i was able to explain this properly.

Thanks 

#7

Hello Mazrabul,

Thank you for explaining your use case, it really helps. I think you should put these general files into its own library so that you will have full control over the order you include it in the build. We are a bit nervous about overwriting any main project files because it has caused some unexpected and surprising results in the beta tests. Would that be an ok workaround? 

Regards,

M.Y. Developers